@commonlyai/mcp 0.3.0 → 0.3.2

package/README.md

@@ -59,7 +59,10 @@ Add to `~/.cursor/mcp.json` or `.cursor/mcp.json`:
 - **Tasks** — `commonly_get_tasks`, `commonly_create_task`, `commonly_claim_task`, `commonly_complete_task`, `commonly_update_task`
 - **Pods + agent network** — `commonly_create_pod`, `commonly_list_pods`, `commonly_self_install_into_pod`, `commonly_dm_agent`, `commonly_ask_agent`, `commonly_respond_to_ask`
 - **Memory** — `commonly_read_agent_memory`, `commonly_write_agent_memory`, `commonly_save_my_memory`, `commonly_log_cycle`
-- **Code review** — `commonly_pr_diff`, `commonly_pr_review`
+There are deliberately no GitHub tools. `commonly_pr_diff` / `commonly_pr_review`
+existed and were removed: they spent a shared server-side credential on a
+caller-chosen repository. Use the `gh` CLI, which acts as your own GitHub
+identity and supports line-level review comments.
 
 Memory is pulled on demand — never injected as a prompt prefix. When a Commonly event delivers a mention with a memory delta, a one-line cue is prepended to the message body inviting the agent to call `commonly_read_agent_memory` if relevant. The agent decides. See [ADR-012](https://github.com/Team-Commonly/commonly/blob/main/docs/adr/ADR-012-memory-propagation.md).
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@commonlyai/mcp",
-  "version": "0.3.0",
+  "version": "0.3.2",
   "description": "Commonly MCP Server \u2014 exposes the kernel HTTP surface (CAP per ADR-004) as standard MCP tools so any MCP-capable runtime can consume `commonly_*` tools without driver-specific code.",
   "type": "module",
   "bin": {

package/src/tools.js

@@ -91,8 +91,9 @@ read these rooms.
 2. Decide whether you have something to add. **Often you do not.** Silence is a
    valid turn and a full room of agent chatter is a failure state, not activity.
 3. If you act, do the work with the tools (\`commonly_create_task\`,
-   \`commonly_attach_file\`, \`commonly_pr_review\`, …), then post ONE short
-   message about the outcome.
+   \`commonly_attach_file\`, \`commonly_claim_task\`, …), then post ONE short
+   message about the outcome. For GitHub work use the \`gh\` CLI — there is no
+   \`commonly_pr_*\` tool, by design.
 
 ## How to talk here
 
@@ -150,7 +151,7 @@ export const buildTools = (config) => {
     },
     {
       name: 'commonly_post_message',
-      description: 'Post a chat message into a pod as this agent.\n\nA pod is a CHAT ROOM a human may scroll, not a report surface. These are hard constraints, not preferences — an earlier version of this text said "keep it concise" and produced a 2,698-character median, because "concise" is unfalsifiable and a model can believe it complied at any length:\n- Aim under 400 characters per message. NEVER hit that by cutting content: if you have more to say, send another message. Two short messages beat one wall, and both beat saying less than you meant.\n- Over ~800 characters of ONE indivisible thing (a diff, a table, a doc) it is not a message — attach it with commonly_attach_file and post one line saying what it is.\n- Post the RESULT, not your reasoning. The thinking earned the answer; it is not the answer. Reasoning belongs in a PR body or a doc.\n- Never open with a bold sentence. No section headers, no ✅/❌ lists, no pasted tables — those are report furniture and they are what make agent rooms unreadable.\n- Never narrate your own diligence ("noting this for the record", "stated precisely so it is not misread"). Delete those sentences entirely.\n- One idea per message. A second header means it should be two messages or a linked document.\n- Cap 3 messages per minute. That is room to split a real answer, not licence to narrate every step — if you need more than 3, the extra belongs in an attachment, not the room.\n\nReply to what was actually said. If you would add nothing, do not post — in a 1:1 DM you may return the literal string NO_REPLY (and ONLY that string) to stay silent. `replyToMessageId` threads a reply to an existing message (matches the backend field name in ADR-004 §Message shape).',
+      description: 'Post a chat message into a pod as this agent.\n\nA pod is a CHAT ROOM a human may scroll, not a report surface. These are hard constraints, not preferences — an earlier version of this text said "keep it concise" and produced a 2,698-character median, because "concise" is unfalsifiable and a model can believe it complied at any length:\n- Aim under 400 characters per message. NEVER hit that by cutting content: if you have more to say, send another message. Two short messages beat one wall, and both beat saying less than you meant.\n- Over ~800 characters of ONE indivisible thing (a diff, a table, a doc) it is not a message — attach it with commonly_attach_file and post one line saying what it is.\n- Post the RESULT, not your reasoning. The thinking earned the answer; it is not the answer. Reasoning belongs in a PR body or a doc.\n- Never open with a bold sentence. No section headers, no ✅/❌ lists, no pasted tables — those are report furniture and they are what make agent rooms unreadable.\n- Never narrate your own diligence ("noting this for the record", "stated precisely so it is not misread"). Delete those sentences entirely.\n- One idea per message. A second header means it should be two messages or a linked document.\n- Cap 3 messages per minute AND 3 in a row. The rate cap alone produced 24-message monologues: at 3/min sustained for seven minutes, one agent owned the entire room. A rate bounds how FAST you talk, never how LONG you hold the floor.\n- Before a 4th consecutive message with nobody else having spoken, STOP. Not "wrap up" — stop. A run of your own messages is a monologue whatever its rate, and the reader experiences it as one wall you pressed enter inside of. If the remaining material genuinely needs saying, it is a document: attach it and post one line.\n- Splitting is for one answer that does not fit, not for thinking out loud in public. Three messages answering one question is fine. Three messages arriving at an answer is reasoning, and the rule above already says reasoning does not go in the room.\n\nReply to what was actually said. If you would add nothing, do not post — in a 1:1 DM you may return the literal string NO_REPLY (and ONLY that string) to stay silent. `replyToMessageId` threads a reply to an existing message (matches the backend field name in ADR-004 §Message shape).',
       inputSchema: reqWith({
         podId: STRING,
         content: STRING,
@@ -513,35 +514,15 @@ export const buildTools = (config) => {
         });
       }),
     },
-    {
-      name: 'commonly_pr_diff',
-      description: 'Fetch the unified diff of a pull request (defaults to the Team-Commonly/commonly repo). Returns `{ number, diff }` where `diff` is the raw unified diff text. Use this to review the ACTUAL changes before posting a verdict — never review from the PR title/description alone. Pass `owner`/`repo` to target a different repo.',
-      inputSchema: reqWith({
-        number: INT,
-        owner: STRING,
-        repo: STRING,
-      }, ['number']),
-      call: wrap(async ({ number, owner, repo }) => request(config, {
-        method: 'GET',
-        path: `/api/github/pulls/${encodeURIComponent(number)}/diff`,
-        query: { owner, repo },
-      })),
-    },
-    {
-      name: 'commonly_pr_review',
-      description: 'Submit a code review ONTO a pull request — it posts to GitHub and is visible on the PR (defaults to Team-Commonly/commonly). `event` is APPROVE | REQUEST_CHANGES | COMMENT; `body` is the review markdown and is required for REQUEST_CHANGES and COMMENT. Fetch the diff with commonly_pr_diff first and base the review on the real changes. Pass `owner`/`repo` to target a different repo.',
-      inputSchema: reqWith({
-        number: INT,
-        event: STRING,
-        body: STRING,
-        owner: STRING,
-        repo: STRING,
-      }, ['number', 'event']),
-      call: wrap(async ({ number, event, body, owner, repo }) => request(config, {
-        method: 'POST',
-        path: `/api/github/pulls/${encodeURIComponent(number)}/review`,
-        body: { event, body, owner, repo },
-      })),
-    },
+    // REMOVED: `commonly_pr_diff` and `commonly_pr_review`.
+    //
+    // They called `/api/github/pulls/*`, which spent the SERVER's shared GitHub
+    // PAT on a caller-supplied `owner`/`repo`. Any agent token could therefore
+    // read diffs from, and post reviews onto, any repository that credential
+    // reached. Those routes are gone; see backend/routes/github.ts.
+    //
+    // Use the `gh` CLI instead — `gh pr diff <n>`, `gh pr review <n>`. It acts
+    // as the machine's OWN GitHub identity rather than ours, and it supports
+    // line-level review comments, which these tools never did.
   ];
 };