@linkbunny/mcp 0.1.2 → 0.1.4

package/README.md

@@ -1,18 +1,20 @@
 # LinkBunny MCP
 
-A local stdio MCP server for owner-authorized LinkBunny workflows. Requires Node.js 22 or later and an account API token supplied as `LINKBUNNY_API_TOKEN` in the process environment.
+A local stdio MCP server that lets your coding agent run LinkBunny nofollow link exchanges for sites you control. Requires Node.js 22 or later and an account API token supplied as `LINKBUNNY_API_TOKEN` in the process environment.
 
-These examples pin the `0.1.2` release.
+Its official MCP Registry name is `com.getlinkbunny/exchange`.
+
+These examples pin the `0.1.4` release.
 
 ```sh
-npx -y @linkbunny/mcp@0.1.2
+npx -y @linkbunny/mcp@0.1.4
 ```
 
 Your MCP client starts this process and communicates over stdin/stdout. Running the command alone waits for protocol input. npm hosts package files; no LinkBunny MCP process is hosted. API requests go only to `https://api.getlinkbunny.com/v1` over HTTPS. There is no endpoint override, daemon, polling, automatic retry, publication, or tool chaining.
 
 ## Configure a client
 
-See [the copyable MCP setup prompt and client examples](https://getlinkbunny.com/docs/agents#mcp). The MCP prompt is separate from the skill installation prompt. Follow preparation → owner authorization for the exact persistent config bundle → registration → native trust/restart → fresh-session discovery.
+See [the copyable MCP setup prompt and client examples](https://getlinkbunny.com/docs/agents#mcp). The MCP prompt is separate from the skill installation prompt. Follow preparation → owner approval of the exact persistent config bundle → registration → native trust/restart → fresh-session discovery.
 
 An agent can inspect the project and prepare registration. Before writing persistent client configuration, it must show the owner the exact client, scope, config paths/diff, executable/version, secret-loading path, and trust/restart steps, then request one explicit authorization for that bundle. Preserve unrelated configuration and keep native trust controls enabled.
 
@@ -23,7 +25,7 @@ For [Codex](https://developers.openai.com/codex/mcp), after authorization merge
 ```toml
 [mcp_servers.linkbunny]
 command = "npx"
-args = ["-y", "@linkbunny/mcp@0.1.2", "--token-file", "/absolute/project/.env.linkbunny"]
+args = ["-y", "@linkbunny/mcp@0.1.4", "--token-file", "/absolute/project/.env.linkbunny"]
 ```
 
 Run `codex mcp list` from the intended project to check registration. Have the owner complete native trust, restart the client, and begin a fresh backing session in Codex or Agent Control before discovery. Same-process hot reload is not proven. Use `/mcp` to check the active server.
@@ -38,7 +40,7 @@ For [Claude Code](https://code.claude.com/docs/en/mcp), after authorization merg
       "command": "npx",
       "args": [
         "-y",
-        "@linkbunny/mcp@0.1.2",
+        "@linkbunny/mcp@0.1.4",
         "--token-file",
         "/absolute/project/.env.linkbunny"
       ]
@@ -57,7 +59,7 @@ For [VS Code](https://code.visualstudio.com/docs/agents/reference/mcp-configurat
     "linkbunny": {
       "type": "stdio",
       "command": "npx",
-      "args": ["-y", "@linkbunny/mcp@0.1.2"],
+      "args": ["-y", "@linkbunny/mcp@0.1.4"],
       "envFile": "${workspaceFolder}/.env.linkbunny"
     }
   }
@@ -80,7 +82,7 @@ An explicit file takes precedence over an inherited token; invalid files never f
 
 A package cached or downloaded by npm is not proof that a server is registered. Check initialization separately after saving the registration. Tokens saved in a secret store or repository environment file are not automatically loaded by the client.
 
-In the fresh session, ask the configured client to perform `initialize`, `tools/list`, `resources/list`, and `resources/read` for `linkbunny://guidance/skill`, then call `get_status` once. Expect server version `0.1.2`, exactly the six tools below, the guidance text, and a status result. `get_status` is read-only and proves token admission without reserving anything. Do not call any other tool to test configuration: even `check_in` can reserve an assignment. If a client cannot list or read resources, report that part as unverified; reading the web skill does not verify MCP resource access.
+In the fresh session, ask the configured client to perform `initialize`, `tools/list`, `resources/list`, and `resources/read` for `linkbunny://guidance/skill`, then call `get_status` once. Expect server version `0.1.4`, exactly the six tools below, the guidance text, and a status result. `get_status` is read-only and proves token admission without reserving anything. Do not call any other tool to test configuration: even `check_in` can reserve an assignment. If a client cannot list or read resources, report that part as unverified; reading the web skill does not verify MCP resource access.
 
 Discovery and resource reads make no LinkBunny API requests. Startup validates token format locally, so only `get_status` proves API token admission and shows subscription state. For isolated discovery-only testing, use the synthetic example `LINKBUNNY_API_TOKEN=synthetic-discovery-only-not-a-real-token-00000000`. It passes the local format check but cannot authorize real API activity. Never substitute a production token merely to test package startup. Discovery-only tests must not invoke `create_profile`, `update_profile`, `check_in`, `report_assignment`, or `reject_assignment`.
 
@@ -103,7 +105,7 @@ In the MyOG.social comparison, the released `0.1.0` resource matched the live ca
 | `report_assignment` | `PUT /assignments/:assignmentID/report` |
 | `reject_assignment` | `PUT /assignments/:assignmentID/reject` |
 
-`get_status` is read-only (`readOnlyHint: true`) and needs no action-time authorization. Every other call requires specific owner authorization. The server cannot establish human consent; the calling agent and client must enforce the canonical guidance and approval controls. Assignments do not authorize publication. The REST API remains authoritative for ownership, entitlement, review, boundaries, settlement, and idempotency.
+`get_status` is read-only (`readOnlyHint: true`) and needs no action-time authorization. Every other call needs the site owner's approval for that action. The server cannot establish human consent; the calling agent and client must enforce the canonical guidance and approval controls. Assignments do not authorize publication. The REST API remains authoritative for ownership, entitlement, review, boundaries, settlement, and idempotency.
 
 Results include validated API `data` or an `error` with a bounded `code` and secret-safe `message`, an HTTP status when received, and `nextAction` guidance. Remote messages are mapped to fixed text. Requests have a 10-second total timeout, a 1 MiB response limit, and redirects disabled. An interrupted or invalid response can leave the operation's outcome unknown. Consult the canonical retry rules rather than submitting another action blindly.
 
@@ -113,7 +115,7 @@ For startup failures, check Node.js 22+, npm access, the effective registration
 
 For stale guidance, restart the server and read its resource again. Compare it with a fresh fetch of the live canonical skill and the exact local skill loaded by the agent. Check duplicate registrations and the package pin before changing caches. Clearing npm's cache does not upgrade a pinned release. Review and refresh a stale local skill through its installer, then reload the agent session; do not merge conflicting copies into a new workflow contract.
 
-Choose a reviewed release and replace the exact version in your client's arguments, then restart the server. Do not replace the pin with `latest` or an unversioned command. For Codex use `codex mcp remove linkbunny`; for Claude Code use `claude mcp remove linkbunny`; for VS Code remove the `linkbunny` server entry from MCP configuration. Revoking an API token is a separate owner-authorized action in the private Account page.
+Choose a reviewed release and replace the exact version in your client's arguments, then restart the server. Do not replace the pin with `latest` or an unversioned command. For Codex use `codex mcp remove linkbunny`; for Claude Code use `claude mcp remove linkbunny`; for VS Code remove the `linkbunny` server entry from MCP configuration. Revoking an API token is a separate action the account owner takes in the private Account page.
 
 ## Development
 

package/dist/index.js

@@ -18,7 +18,7 @@ var STATUS_PAGE_LIMIT = 100;
 var REQUEST_TIMEOUT_MS = 1e4;
 var MAX_RESPONSE_BYTES = 1048576;
 var SKILL_URI = "linkbunny://guidance/skill";
-var VERSION = "0.1.2";
+var VERSION = "0.1.4";
 
 // src/privacy.ts
 function redact({

package/dist/skill.md

@@ -30,6 +30,34 @@ billing, credential, site, assignment, publication, report, or rejection actions
 carry out an authorized website action only when it has explicitly authorized browser control, and
 may carry out an authorized API or site action only within the approval given.
 
+### Before the owner has an account
+
+When the owner asks you to set up LinkBunny and has no account or API token yet:
+
+1. Plan locally. Inspect the project and propose one HTTPS target URL and one HTTPS area of the
+   site where nofollow links can go, both on the same registrable domain. Tell the owner the price
+   ($20/month for up to 10 sites, no per-link fees), that profiles are reviewed before they can
+   match, that some check-ins return no request, and which later steps need their approval. Make
+   no LinkBunny API call while there is no token.
+2. With the owner's OK, open `https://getlinkbunny.com/login?redirect=%2Faccount%3Fsetup%3Dagent`
+   in their browser, or print it when you cannot open a browser (for example in a cloud or remote
+   session). Opening the link is not browser control: do not read, click, fill, or otherwise
+   operate the page. The owner signs in, subscribes, and creates the API token there.
+3. With the owner's OK, create a project file `.env.linkbunny` containing only an empty
+   `LINKBUNNY_API_TOKEN=` line and make sure Git ignores it, or use another secret store the owner
+   chooses. The owner pastes the token there. Never ask for the token in chat, and never print,
+   log, or commit the file's contents.
+4. When the owner says the token is saved, make one read-only `GET /me` (see "Status"). Keep the
+   token out of command arguments and output, for example:
+   `tr -d '\r' < .env.linkbunny | sed -nE 's/^(export )?LINKBUNNY_API_TOKEN="?([A-Za-z0-9._~-]+)"?$/header = "Authorization: Bearer \2"/p' | curl -sS -w '\nHTTP %{http_code}\n' --config - https://api.getlinkbunny.com/v1/me`.
+   If the LinkBunny MCP server is already configured with that token file, its `get_status` tool
+   makes the same read. `subscriptionActive: true` confirms setup. `401` means the token is missing
+   or wrong in the file; `subscriptionActive: false` means the subscription is not confirmed yet,
+   so ask the owner to finish or refresh it on the account page. Do not poll; wait until the owner
+   says it is done again.
+5. Only after `subscriptionActive: true`, continue with "A — Create a profile". Ask the owner
+   before registering the site.
+
 ## Activation and approval gates
 
 Use LinkBunny only when the owner explicitly asks you to onboard, register an owned site, check that

package/npm-shrinkwrap.json

@@ -1,12 +1,12 @@
 {
   "name": "@linkbunny/mcp",
-  "version": "0.1.2",
+  "version": "0.1.4",
   "lockfileVersion": 2,
   "requires": true,
   "packages": {
     "": {
       "name": "@linkbunny/mcp",
-      "version": "0.1.2",
+      "version": "0.1.4",
       "license": "MIT",
       "dependencies": {
         "@modelcontextprotocol/server": "2.0.0",

package/package.json

@@ -1,7 +1,8 @@
 {
   "name": "@linkbunny/mcp",
-  "version": "0.1.2",
-  "description": "Local stdio MCP tools for owner-authorized LinkBunny workflows",
+  "version": "0.1.4",
+  "mcpName": "com.getlinkbunny/exchange",
+  "description": "Local stdio MCP server for LinkBunny nofollow link exchanges. Requires a LinkBunny account API token.",
   "type": "module",
   "bin": {
     "linkbunny-mcp": "dist/index.js"
@@ -24,8 +25,8 @@
     "build": "tsc --noEmit && bun scripts/build.ts",
     "type-check": "tsc --noEmit && tsc -p tsconfig.test.json",
     "test": "bun run build && bun test test",
-    "lint": "prettier --check src scripts test package.json tsconfig.json tsconfig.test.json README.md",
-    "format": "prettier --write src scripts test package.json tsconfig.json tsconfig.test.json README.md",
+    "lint": "prettier --check src scripts test package.json server.json tsconfig.json tsconfig.test.json README.md",
+    "format": "prettier --write src scripts test package.json server.json tsconfig.json tsconfig.test.json README.md",
     "prepack": "bun run build && bun scripts/resource.ts --check",
     "verify:package": "bun scripts/verify-package.ts"
   },