Skip to main content
Glama
Sign In
Align CLI

Align CLI

Official
by aligndottech
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

align_scope

View or change which connected-source items (your own or a team’s in GitHub, Jira, Linear, GitLab, or Confluence) are read into the local graph; use set to include team items or revert to yours.

Instructions

See, or change, what the sources the user has ALREADY connected read into the local graph on this machine: only their own items, or everyone's in one named GitHub repo, Jira project, Linear team, GitLab project or Confluence space that their token can see. action "view" lists each connected source's scope (and any change waiting for the person); use it when asked what is read or why teammates' items are missing. action "set" changes one source; offer it when the user asks to include their team's items, or to go back to only their own. A Jira project can be narrowed to one board, and a Linear team to some of its projects. Widening re-reads that source's history on its next sync (a few minutes; the reply says how far back). It deletes nothing and reads other people's items onto this machine only. A team change you make WAITS: nothing reads it, in the background or via align_sync, until a person runs align sync <source> at a terminal, which shows what it reads and asks (default No). Tell them so, with the reply's disclosure sentence in your own words. That prompt is a speed bump, not proof of consent: an agent with shell access could answer it from a pseudo-terminal, and you must never do that. Narrowing to their own items is immediate. Zoom is only the user's own; Slack and Teams already read all their token can see, and so does Notion unless the person picked pages. 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_scope"
  }
}

Input Schema

NameRequiredDescriptionDefault
repoNoGitHub: the repo as owner/repo
boardNoJira, with exactly one key in "projects": read only the issues on this board (its id or exact name)
scopeNoWith "set": "yours" goes back to only the user's own items. "team" is implied by passing the source's value below
teamsNoLinear: team keys, for example ["ENG"]
actionYesview: show the scopes. set: change one source's scope
sourceNoWith "set": which connected source to change
spacesNoConfluence: space keys, for example ["ENG"]
projectsNoJira: project keys, for example ["ALI","OPS"]
gitlab_projectNoGitLab: the project id or group/project path
linear_projectsNoLinear, with exactly one key in "teams": read only these projects (names or ids)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Since annotations only mark this as non-read-only and non-destructive, the description adds real behavioral context: widening re-reads history on the next sync and the reply says how far back, nothing is deleted, and reads of other people's items stay on this machine. The most important disclosure is that a team change waits for a person to run `align sync`, that the prompt is a speed bump rather than proof of consent, and that the agent must never answer it from a pseudo-terminal. This is far beyond what the annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is worthwhile, but it is delivered as a dense paragraph of long, multi-clause sentences, some of which pack three or four ideas at once. "It deletes nothing and reads other people's items onto this machine only" partly restates the surrounding thought. The view guidance is front-loaded well, but the whole needs re-reading to parse.

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?

For a 10-parameter tool with no output schema, the description covers what the reply contains (each source's scope, any pending change, the disclosure sentence, the connect command), the timing of sync effects, and the consent boundary for the agent. Nothing an agent would need in order to call this correctly is missing.

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 the baseline is 3, but the description adds meaning the schema does not: scope "team" is implied by passing the source's value, a Jira project can be narrowed to one board, and a Linear team to a subset of its projects. Source-specific caveats (Zoom, Slack, Teams, Notion) further constrain how parameters should be chosen.

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?

The description names the exact resource (which already-connected sources read into the local graph) and the two concrete operations: action "view" lists each source's scope, action "set" changes one source. It distinguishes itself from align_sync by saying a team change waits until a person runs `align sync <source>` at a terminal. The opening sentence is convoluted and has to be re-read, which keeps it short of a 5.

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?

It gives explicit triggers for each action: use "view" when asked what is read or why teammates' items are missing, and offer "set" when the user asks to include their team's items or to go back to only their own. It also states the exclusions — Zoom is only the user's own, Slack/Teams already read all their token can see, and a source that is not connected needs `align connect <source>` run by the user. Nothing is left to inference.

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

Deploy Server

Other Tools