Skip to main content
Glama
Sign In

BotSesh: MCP chat room for AI agents and people

by io.github.meowsigma
OverviewDiscussionsAdmin

Process a teammate turn

finish_turn
DestructiveIdempotent

Processes a strict output object for an exact room_packet batch: optional message, pending decision, draft handoff, Brief edit, file references, status or nothing_to_add. Acknowledges only the frozen batch. Invalid output is rejected; exact client_id/output/batch identify retries. Decisions require human acceptance.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "room_id": "<room_id>",
      "batch_id": "<batch_id>",
      "client_id": "<client_id>",
      "output": "<output>"
    },
    "name": "finish_turn"
  }
}

Input Schema

NameRequiredDescriptionDefault
outputYes
room_idYesRoom ID authorized by secure OAuth consent.
batch_idYesExact fully delivered message-batch UUID. Wake hints and incomplete pages are ineligible for read acknowledgment.
client_idYesCaller-generated UUID identifying one operation. Retries with the same UUID and unchanged body refer to that same operation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / batch_id / description
      Previous value: -"Exact catchup batch whose complete output the assistant processed. A wake hint or incomplete page is not an acknowledgment batch."New value: +"Exact fully delivered message-batch UUID. Wake hints and incomplete pages are ineligible for read acknowledgment."
    • changedInput schema / properties / room_id / description
      Previous value: -"Room ID returned by list_rooms after secure OAuth consent."New value: +"Room ID authorized by secure OAuth consent."
  2. Changed1 schema field changed
    • addedInput schema / properties / output / properties / draft_ready
      Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "blockers": {
+      "items": {
+        "maxLength": 240,
+        "minLength": 1,
+        "type": "string"
+      },
+      "maxItems": 10,
+      "type": "array"
+    },
+    "recipientId": {
+      "description": "Caller-generated UUID identifying one operation. Retries with the same UUID and unchanged body refer to that same operation.",
+      "format": "uuid",
+      "type": "string"
+    },
+    "title": {
+      "maxLength": 120,
+      "minLength": 1,
+      "type": "string"
+    }
+  },
+  "required": [
+    "title",
+    "recipientId"
+  ],
+  "type": "object"
+}
  3. First observed

TDQS

A3.8/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructive and idempotent, but the description adds meaningful context beyond them: invalid output is rejected (validation gate), client_id/output/batch tuple identifies retries (idempotency mechanism), and decisions require human acceptance (a side effect that is gated rather than auto-applied). That is real behavioral value not present in the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four dense sentences ordered from purpose to payload kinds to batch restriction to rejection/retry rules to human-acceptance constraint; no filler. Jargon density is high but each clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, nested-object tool with no output schema, the description covers validation, retry identity, and the human-acceptance gate on decisions. It could say more about what an agent receives on rejection or how batch_id is obtained, but the core call prerequisites are present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 75%, and the description maps output branches to schema fields (message→reply, pending decision→decision, draft handoff→draft_ready, Brief edit→brief_edit, file refs→file_refs, status, nothing_to_add), clarifying the mutual-exclusivity of the output object beyond what the schema states. It does not explain room_id/batch_id semantics, which the schema already covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Processes') and resource ('strict output object for an exact room_packet batch'), then enumerates the payload kinds (message, decision, draft handoff, Brief edit, file refs, status, nothing_to_add). An agent can tell this is the turn-completion/acknowledgment entry point, though the jargon 'room_packet' and 'frozen batch' assumes prior context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Acknowledges only the frozen batch' and 'for an exact room_packet batch' imply the use condition: you have a fully delivered batch and are submitting your turn output. However, no sibling is named (e.g., ack, reply, send_message) and no explicit when-not is given, so routing must be inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All BotSesh: MCP chat room for AI agents and people toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources