Align CLI

Official

Overview Schema Source Related Servers Discussions Admin

align_check_alignment

Read-only

Check a proposed code change against prior decisions across Slack, Jira, GitHub, and git before editing to surface conflicts or unknown checks that require human confirmation.

Instructions

BEFORE writing or changing significant code, call this with the proposed change to surface prior decisions across ALL the user's tools (Slack, Jira, GitHub, git) that it conflicts with or relates to. A "conflict" status means the change opposes a past decision - stop and confirm with the user before proceeding. An "unknown" status means the check could not run and is NOT a pass: the decisions it returns are unchecked, so stop and ask the human rather than treating it as clear. Pass a real unified diff when you have one, and name the files you intend to change: the decisions that wrote those lines are checked too (found_by: blame-lines or blame-file).

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": {
      "diff": "<diff>"
    },
    "name": "align_check_alignment"
  }
}

Input Schema

Name	Required	Description	Default
`diff`	Yes	Unified diff of the proposed change if you have one, else a description that names the files to change
`context`	No	Additional context (branch name, PR title)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: the conflict and unknown status semantics, the instruction that unknown is not a pass, and the found_by values blame-lines/blame-file. What it omits is the response shape and cost/latency characteristics of scanning across four systems.

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?

Front-loaded with the critical 'BEFORE' trigger, then the two status rules and the input guidance in priority order. Slightly redundant with the schema on the diff parameter, but no sentence is pure filler.

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?

With no output schema, the description carries the burden of explaining return semantics and does so for the two states an agent must act on, plus the found_by field values. An agent knows what to expect and what to do with each result.

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 100% and the description largely restates the schema's own wording ('pass a real unified diff when you have one... name the files'). The added value is indirect: it explains that naming files causes line-level decisions to be checked, which links the diff parameter to the found_by output.

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 ('check alignment') and object (the proposed change) plus the scope of evidence consulted: prior decisions across Slack, Jira, GitHub and git. The pre-change framing makes it distinguishable from sibling lookups like align_get_conflicts or align_search.

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 explicit timing ('BEFORE writing or changing significant code') and an explicit decision rule per outcome — stop on conflict, stop and ask on unknown. It does not name alternative tools or state when not to use it, so it falls short of a full when/when-not/alternatives treatment.

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

Deploy Server