Skip to main content
Glama
nickgeorgeseo

fieldtwin

by nickgeorgeseo
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List changes since a checkpoint

twin_changes
Read-only

Lists what changed since a checkpoint, one line per event oldest first, and can filter to API-originated changes only; read-only and does not alter data.

Instructions

What changed since a checkpoint, one line per event, oldest first: when, which vendor, what, and its source. Set onlyFromApi to see only what your code's API calls did. Changes nothing. For whole events, use twin_export_log.

Input Schema

NameRequiredDescriptionDefault
checkpointYesA checkpoint's name, as given to twin_checkpoint
onlyFromApiNoTrue to leave out the seed, the scenario timeline, and control tools

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.5.3
    • addedInput schema / properties / checkpoint / description
      Added value: +"A checkpoint's name, as given to twin_checkpoint"
    • addedInput schema / properties / onlyFromApi / description
      Added value: +"True to leave out the seed, the scenario timeline, and control tools"
  2. First observedv0.5.2

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description's 'Changes nothing' is consistent with that. It adds behavior beyond the annotations: output is ordered oldest first, one line per event, with specific fields, which helps the agent interpret results.

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?

Three short sentences, front-loaded with the core purpose and output shape, then the parameter hint, then the safety note and the alternative. No wasted text.

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

Completeness5/5

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

There is no output schema, but the description compensates by explaining the per-event line contents and ordering. With the parameters fully documented and read-only behavior stated, nothing needed for a correct call is missing.

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 100%, so the baseline is 3. The description adds framing for onlyFromApi ('see only what your code's API calls did') that complements the schema's 'leave out seed, scenario timeline, control tools' wording, making the practical effect clearer.

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

Purpose5/5

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

States a specific verb and resource ('what changed since a checkpoint') and even describes the output shape: one line per event, oldest first, with when/vendor/what/source. It also names the sibling to use for whole events (twin_export_log), so an agent can distinguish it without opening a schema.

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?

Explicitly routes the agent to twin_export_log 'for whole events' and explains the onlyFromApi narrowing case. It gives a clear usage context but stops short of stating when this tool should not be used at all (e.g., no checkpoint yet).

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

Deploy Server

Other Tools