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

Annotations already cover safety (readOnly, idempotent, non-destructive, open-world), so the remaining burden is light. The description usefully adds cursor chaining (feed `until` back in) and an auth prerequisite ("Needs a key"), but leaves unclear what a 'key' scopes, whether results are truncated, and how large a delta can be returned.

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?

It is a single run-on sentence with a mid-sentence hyphen and clause nesting ("since `since` ... that the key holds") that forces re-reading. The critical format hint is buried mid-sentence and the prerequisite is tacked onto the end as "Needs a key."

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?

With no output schema, the description should explain the response shape, but it only mentions an `until` field that appears nowhere in structured data and never defines what the returned entries contain. The vague term 'the key' leaves a core requirement undefined for an incremental-sync tool.

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 coverage is 0%, so the description must carry the parameter meaning, and it does supply the accepted format 'YYYY-MM-DD HH:MM:SS' and the role of `since` as the window start. It doesn't clarify timezone or boundary inclusivity, and it references an `until` field that isn't a declared parameter or documented in any output schema.

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 conveys that this returns a delta of repaired values since a timestamp, which is more specific than the title alone. But phrasing like "Every value our checks repaired since `since` ... that the key holds" is opaque about what 'checks' and 'the key' are, and it never clearly states the resource being returned (a change list).

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?

It does give a usable pattern: apply the returned values to keep a copy correct, and pass the response's `until` back as the next `since`. However, it names no alternative sibling tool (e.g. tilla_latest, tilla_window) and gives no conditions under which not to use it.

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