Align CLI

Official

Overview Schema Source Related Servers Discussions Admin

align_sync

Check connected source sync status or start a background refresh of the local graph, and estimate AI classification costs without handling tokens.

Instructions

Check on, or start, the refresh of the sources the user has ALREADY connected into the local graph on this machine. action "status" says per source when it last synced, whether it needs the person to re-authenticate, and what is still waiting; use it when the user asks whether the graph is up to date or why something is missing. action "run" starts a background refresh now (it only reads from the sources, makes no LLM calls, and returns at once). action "classify_estimate" says what typing the imported items with the user's own AI key would cost, plus the command for the user to run; it cannot start that. It never takes a token or key: for a source that is not connected, or whose saved token was refused, the reply gives the exact align connect <source> command for the user to run themselves. Do not ask the user to paste a token into the chat.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>"
    },
    "name": "align_sync"
  }
}

Input Schema

Name	Required	Description
`max`	No	With "classify_estimate": how many items the person would classify (default 25)
`action`	Yes	What to do
`source`	No	With "run": only this source. Default: every connected source

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only say readOnlyHint=false and destructiveHint=false; the description adds substantial context beyond that — 'run' starts a background refresh that returns at once and makes no LLM calls, 'classify_estimate' only estimates and prints a command the user must run, and the tool never accepts a token or key. That is exactly the operational detail an agent needs before invoking a non-read-only tool.

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?

Purpose is front-loaded, then one clause per action, with the token/security rule last — a logical order with no filler sentences. It is dense and somewhat run-on, and the token-command sentence partially overlaps the closing 'Do not ask the user to paste a token' warning, keeping it from top marks.

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?

With no output schema, the description carries the burden of describing returns and does so action-by-action, including what status reports and that run returns immediately. It omits the concrete response shape and failure modes (e.g. what happens if no source is connected), leaving a small gap for a three-parameter mutation-adjacent tool.

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 baseline is 3, but the description goes further by explaining what each 'action' enum value actually yields (per-source last sync, re-auth need, pending items for status; estimated cost plus command for classify_estimate) and what 'source' does for 'run' (defaults to every connected source). Only 'max' is left entirely to the schema, hence not a 5.

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?

Opens with a specific verb+resource ('check on, or start, the refresh of the sources the user has ALREADY connected into the local graph on this machine') and then breaks the tool into its three actions, each with its own verb and outcome. An agent can tell immediately this is about local-graph source synchronization rather than search, capture, or backfill.

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?

Gives an explicit trigger for 'status' ('use it when the user asks whether the graph is up to date or why something is missing') and states what classify_estimate cannot do ('it cannot start that'), plus a strong negative instruction ('Do not ask the user to paste a token into the chat'). It stops short of naming any sibling tool or contrasting with them, so the when-to-use guidance is clear but not comparative.

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

Deploy Server