timetree-worklog-mcp

Overview Schema Source Related Servers Discussions Admin

Retry pending work-log synchronization

retry_pending_sync

Reconcile pending, failed, or uncertain work logs before retrying sync. Default dry runs verify memos and conflicts; live retries require remote writes enabled and explicit confirmation.

Instructions

Reconcile pending, failed or uncertain work logs before any retry. Defaults to dryRun: true; a dry run records a verified memo or conflict but does not persist an empty listing as absence. A live retry requires remote writes enabled and confirmation RETRY, is limited to 10 work logs per call, never retries CONFLICT, FAILED_PERMANENT, BLOCKED or NOT_PUBLISHED records, and never performs a first publication. Re-verifies every created memo. Never assume a timeout means no memo.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "retry_pending_sync"
  }
}

Input Schema

Name	Required	Description
`dryRun`	No	Defaults to true. A live retry requires explicit confirmation.
`worklogId`	No
`confirmation`	No

Output Schema

Name	Required	Description	Default
`ok`	Yes
`data`	No
`error`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations by explaining that a dry run records a verified memo or conflict but does not persist an empty listing as absence, that live retries are capped at 10 work logs per call, that every created memo is re-verified, and that a timeout must not be read as 'no memo'. These are substantive behavioral constraints an agent could not infer from destructiveHint=false or openWorldHint=true.

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?

The dry-run default and the confirmation gate are front-loaded, and nearly every clause carries a distinct constraint. The closing 'Never assume a timeout means no memo' is slightly cryptic but still earns its place as a caution against misreading failure modes.

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 mutating, non-idempotent tool this covers dry-run vs live semantics, prerequisites, retry limits, excluded states, and post-write verification. With an output schema present the return values need not be described, but the unresolved meaning of worklogId leaves a small gap.

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 coverage is only 33%, and the description compensates for two of three parameters — the dryRun default and the RETRY confirmation gate — which is genuinely useful. However, worklogId is left unexplained, and it is ambiguous whether it targets a single work log or narrows the batch implied by 'limited to 10 work logs per call'.

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 and resource ('Reconcile pending, failed or uncertain work logs') with the scope of the reconciliation. It also implicitly separates itself from publish_worklog by stating it 'never performs a first publication', though it never names a sibling tool directly.

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

Usage Guidelines5/5

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

Explicitly says when to run it (before any retry), what the default mode is (dryRun: true), and what a live retry requires (remote writes enabled plus confirmation RETRY). It also lists clear exclusions — CONFLICT, FAILED_PERMANENT, BLOCKED, NOT_PUBLISHED — and rules out first publications, routing that case elsewhere.

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

Deploy Server