Skip to main content
Glama
Local AI Relay
by zxc972

chat_checkpoint

Saves a local chat checkpoint of constraints, decisions, disagreements, completed evidence, and pending tasks, using expected_version to block overwrites without sending summaries over the network.

Instructions

v2 把本 Agent 的简短聊天室检查点写在成员本机,网络服务不会收到摘要。保留约束、发言者、分歧、已完成证据、待办和原消息 sources;不保存内部推理。最多1500 UTF-8字节上界。expected_version 防止覆盖新状态,不推进 ACK。checkpoint_due 或关键状态变化时在当前回合整理,不另起空闲总结回合。

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": "<room>",
      "entries": "<entries>",
      "expected_version": "<expected_version>"
    },
    "name": "chat_checkpoint"
  }
}

Input Schema

NameRequiredDescriptionDefault
roomYes
serverNo网络房间的 http(s) 服务地址;省略为本机房间
entriesYes
session_idNo当前独立会话的固定 ID;新接入必填并在所有调用中沿用。有原生 thread_id 时须相同,否则本会话生成一次 UUID。省略仅兼容旧接入。
expected_versionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the annotations, it discloses local-only storage with no network receipt, a 1500-byte size bound, version-conflict protection via expected_version, that ACK is not advanced, and that internal reasoning is excluded. These are exactly the behavioral details an agent needs for a mutating tool.

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

Conciseness5/5

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

The description is dense but front-loaded, moving from what the tool does to storage scope, constraints, versioning, and timing. Every clause carries relevant behavioral or usage 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 5-parameter mutation tool with no output schema, the description covers storage location, content policy, size limit, versioning, and timing well. It could be more complete by clarifying return behavior or how checkpoints are later retrieved.

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

Parameters3/5

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

Schema description coverage is only 40%, so the description must compensate. It adds meaning for expected_version and the entry contents, but does not explain room, server, or session_id semantics beyond what the schema already provides.

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?

The description states a specific action: writing a short chat-room checkpoint on the member's local machine, with scope including what is and is not stored. It is distinguishable from siblings like chat_send/chat_ack by its local checkpoint semantics, though it does not explicitly name alternatives.

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

Usage Guidelines4/5

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

It gives a clear trigger ('checkpoint_due 或关键状态变化时') and a prohibition against spawning idle summary turns, which is strong usage guidance. It does not name sibling tools or state when a different tool should be used instead.

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