Skip to main content
Glama

sync

Destructive

Downloads Goodreads API data into a local SQLite database for instant full-text search, supporting resumable incremental updates and full refreshes.

Instructions

Sync data from the API into a local SQLite database. Supports resumable incremental sync (only fetches new data since last sync) and full resync. Once synced, use the 'search' command for instant full-text search.

Exit codes & warnings: Resources the API denies access to (HTTP 403, or HTTP 400 with an access-policy body) are reported as warnings rather than failing the run. In --json mode each is emitted as a {"event":"sync_warning",...} line carrying status, reason, and message fields, and a final {"event":"sync_summary",...} aggregates the run.

Exit 0 when at least one resource synced and no resource flagged in the spec as critical (x-critical: true) failed; non-critical failures emit {"event":"sync_warning","reason":"exit_policy_default_changed", ...} so callers can detect that a partial failure was tolerated. Pass --strict to exit non-zero on any per-resource failure. Exit is always non-zero when every selected resource failed, regardless of --strict.

Input Schema

NameRequiredDescriptionDefault
dbNoDatabase path (default: ~/.local/share/goodreads-cli/data.db)
csvNoOutput as CSV (table and array responses) (default: false)
yesNoSkip confirmation prompts (for agents and scripts) (default: false)
fullNoFull resync (ignore previous checkpoint) (default: false)
jsonNoOutput as JSON (default: false)
agentNoSet all agent-friendly defaults (--json --compact --no-input --no-color --yes) (default: false)
plainNoOutput as plain tab-separated text (default: false)
quietNoBare output, one value per line (default: false)
sinceNoIncremental sync duration (e.g. 7d, 24h, 1w, 30m)
configNoConfig file path
selectNoComma-separated fields to include in output (e.g. --select id,name,status)
strictNoExit non-zero on any per-resource failure (default: only critical failures or all-resource failure exit non-zero). (default: false)
compactNoReturn only key fields (id, name, status, timestamps) for minimal token usage (default: false)
deliverNoRoute output to a sink: stdout (default), file:<path>, webhook:<url>
dry-runNoShow request without sending (default: false)
profileNoApply values from a saved profile (see 'goodreads profile list')
timeoutNoRequest timeout (default: 30s)
no-cacheNoBypass response cache (default: false)
no-colorNoDisable colored output (default: false)
no-inputNoDisable all interactive prompts (for CI/agents) (default: false)
max-pagesNoMaximum pages to fetch per resource (0 = unlimited; cap-hit emits a sync_warning event) (default: 100)
resourcesNoComma-separated resource types to sync
idempotentNoTreat already-existing create results as a successful no-op (default: false)
rate-limitNoMax requests per second (0 to disable) (default: 0)
concurrencyNoNumber of parallel sync workers (default: 4)
data-sourceNoData source for read commands: auto (live with local fallback), live (API only), local (synced data only) (default: auto)
latest-onlyNoRefresh head of each resource only; clears resume cursor and caps pages at 1. Mutually exclusive with --since (--since wins). (default: false)
human-friendlyNoEnable colored output and rich formatting (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior5/5

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

The description adds substantial behavior beyond the annotations: denied resources are warnings rather than hard failures, JSON warning/summary events are emitted, and exit status depends on critical-resource policy and --strict. This is exactly the kind of operational context an agent needs for a non-idempotent, open-world sync.

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 core purpose and search handoff are front-loaded, and the exit-code section is organized under a clear heading. The exit-policy prose is dense and quite long, but it remains relevant for a sync tool whose failure semantics matter.

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?

Given the rich schema and annotations, the description covers the essential sync model, incremental/full behavior, warnings, and exit codes. It does not explicitly restate destructive local-write implications or authentication requirements, but the destructive and open-world annotations already signal those risks.

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?

With 100% schema description coverage across 28 parameters, the schema already carries most parameter meaning. The description adds useful context for 'since', 'full', 'strict', and '--json' behavior, but it does not systematically explain the many output, routing, cache, concurrency, and resource-selection parameters.

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?

The description states a specific verb and resource: syncing API data into a local SQLite database. It also distinguishes the post-sync query path by naming the 'search' command, so an agent can tell what this tool is for without opening the 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?

It clearly frames the tool as populating local data for later search and explains incremental vs. full resync and when to use --strict. It does not explicitly exclude or compare against siblings such as 'import' or 'sql', so it stops short of full when/when-not guidance.

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