@intangle/mcp-server 2.6.22 → 2.6.24

package/dist/tool-definitions.js

@@ -668,7 +668,7 @@ const BASE_TOOLS = [
     {
         name: "fetch_conversation_messages",
         title: "Fetch Conversation Messages",
-        description: "Read persisted messages from a conversation/chat summary. Use this to poll shared threads after async `message` calls and to fetch only new messages via `since_timestamp` instead of reloading the whole thread. External agents should pass stable participant fields so unread counts and subscriptions stay consistent.",
+        description: "Read persisted messages from a conversation/chat summary. Use this to poll shared threads after async `message` calls and to fetch only new messages via `since_timestamp` instead of reloading the whole thread. External agents should pass stable participant fields so unread counts and subscriptions stay consistent. Each assistant message carries `write_outcomes`: what its Item write tools actually returned, as `status` (`none` when no Item write ran, `succeeded`, `failed` or `partial`), `written` (Item `id` and returned `updated_at`) and `failed` (Item `id`, `tool` and `error`). Treat that, not the reply text, as the record of whether a requested write happened, and resend or report when it shows `none`, `failed` or `partial`.",
         inputSchema: {
             type: "object",
             properties: {
@@ -825,7 +825,7 @@ const BASE_TOOLS = [
     {
         name: "message",
         title: "Message Assistant",
-        description: "Primary way to use Intangle for memory, communicating and collaborating with Tan agent in a shared thread. Send a request and either wait for one assistant turn to complete or submit asynchronously for later polling. Intangle derives the durable participant identity from the authenticated runner rather than caller-supplied fields. Conversations are backed by `summary_*` IDs; reuse the returned `conversation_id` and reuse the returned `session_id` so callers can continue the same thread reliably across turns. For shared Item coordination, pass the stable Item Room identity as `channel_id` using `item|<item_id>`; this Item room/channel coordinate is preferred. `project_id`, `group_id`, and legacy `project|...` or `group|...` channel values remain accepted only as compatibility coordinates for older stored calls and integrations. The stable idempotency key anchors retries to one durable turn, and the returned `conversation_id` remains the durable thread anchor. Callers should fill `sender` on every call: `model` is the model sending this message, `session_name` is the name of your session or thread, and `agent_name` is your own name when you are a persistent named assistant or bot. Intangle shows your verified client first and then these labels (model and session, or the agent name with the model), and may shorten a value or leave it out, for example when it matches a person in the Space or Tan. These are display labels only; they never change who you are or what you may do.",
+        description: "Primary way to use Intangle for memory, communicating and collaborating with Tan agent in a shared thread. Send a request and either wait for one assistant turn to complete or submit asynchronously for later polling. Intangle derives the durable participant identity from the authenticated runner rather than caller-supplied fields. Conversations are backed by `summary_*` IDs; reuse the returned `conversation_id` and reuse the returned `session_id` so callers can continue the same thread reliably across turns. For shared Item coordination, pass the stable Item Room identity as `channel_id` using `item|<item_id>`; this Item room/channel coordinate is preferred. `project_id`, `group_id`, and legacy `project|...` or `group|...` channel values remain accepted only as compatibility coordinates for older stored calls and integrations. The stable idempotency key anchors retries to one durable turn, and the returned `conversation_id` remains the durable thread anchor. Callers should fill `sender` on every call: `model` is the model sending this message, `session_name` is the name of your session or thread, and `agent_name` is your own name when you are a persistent named assistant or bot. Intangle shows your verified client first and then these labels (model and session, or the agent name with the model), and may shorten a value or leave it out, for example when it matches a person in the Space or Tan. These are display labels only; they never change who you are or what you may do. When you ask Tan to write to Items, confirm the write from the turn itself, not the reply text: a waited response includes `tool_calls` and `tool_results`, and after an asynchronous submit the reply in `fetch_conversation_messages` carries `write_outcomes`.",
         inputSchema: {
             type: "object",
             properties: {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@intangle/mcp-server",
-  "version": "2.6.22",
+  "version": "2.6.24",
   "description": "Model Context Protocol server for Intangle - AI context that persists across conversations",
   "main": "dist/index.js",
   "type": "module",
@@ -56,5 +56,5 @@
     "tsx": "^4.0.0",
     "typescript": "^5.0.0"
   },
-  "intangleSourceHash": "9dea3964a786eb78e3e4041fe3d4f1dbe7317c72b06cd6d3a25b8ae89505d224"
+  "intangleSourceHash": "5cb38a0c81a2dc05ba08e657c91f229e25d804f44abc65806befb973988669be"
 }