현재 키 값과 체크포인트 값의 diff를 반환합니다. 또는 두 임의 값의 diff 비교.
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | 비교할 키 (체크포인트 비교 시 필수) | |
| value_a | No | 직접 비교할 첫 번째 값 (선택사항) | |
| value_b | No | 직접 비교할 두 번째 값 (선택사항) | |
| session_id | Yes | 세션 식별자 | |
| checkpoint_tag | No | 비교 기준 체크포인트 태그 |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'returns diff' and does not reveal whether the operation is read-only, how it handles missing keys or checkpoints, or what happens if conflicting parameters (e.g., key and value_a) are supplied together. The ambiguity between the two modes is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, immediately states the primary function and the alternative mode. Every word earns its place, with no redundancy or fluff. It is ideally sized for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has five parameters and two distinct modes, but the description does not map the modes to the parameters. An agent would not know whether to use key/checkpoint_tag or value_a/value_b, nor what the output diff is. With no output schema and no annotations, this level of under-specification leaves important gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some value by mentioning 'current key value' and 'two arbitrary values,' hinting at parameter groups (key/checkpoint_tag vs. value_a/value_b), but it does not specify which parameters belong to which mode or how they interact. The schema already documents each parameter clearly, so the description's extra semantics are modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a diff between a current key value and a checkpoint, or between two arbitrary values. It uses a specific verb ('returns diff') and identifies the resource (scratchpad), and the two modes distinguish it from sibling tools like read, write, and list. However, it could be more explicit about what form the diff takes (e.g., textual, structural) or when each mode applies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparing values or checking differences versus a checkpoint, but it does not explicitly state when to prefer this over related tools like scratchpad_read or scratchpad_checkpoint. It lacks direct guidance on choosing between the two diff modes or prerequisites like needing a checkpoint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: checkpoint saves snapshots, delete removes keys, diff compares values, list enumerates keys, read retrieves values, and write stores values. No overlap or ambiguity exists among them.
All tools follow a consistent 'scratchpad_' prefix with a concise verb (checkpoint, delete, diff, list, read, write). The snake_case naming is uniform and predictable.
Six tools is well-scoped for a key-value store with checkpointing functionality. Each tool serves a distinct and necessary purpose without redundancy or bloat.
The surface covers the core CRUD operations (write, read, list, delete) plus checkpointing and diffing. A restore-from-checkpoint operation is missing, but agents can work around this by reading checkpoint values and writing them back.