FlightPlan

list_intents

Query in-flight and recent team work to detect semantic or glob collisions before posting an intent, or search summaries and outcomes for context.

Instructions

Query in-flight and recent work across the team. Three distinct uses — pick exactly one: (1) pre-planning semantic check — pass summary (and optionally overlaps globs) to get judge-assessed semantic overlap before you post_intent; this is the strong collision check; (2) fast glob collision check — pass overlaps alone (no summary, no q) for deterministic prefix matching; (3) context search — pass q and since (add match=any for recall if a precise query returns nothing) to search summaries and outcomes including completed work. q and overlaps are AND-combined: a descriptive q alongside overlaps filters out overlapping intents whose summaries don't contain your words — for a collision check, omit q. q matches per-word (all words must appear, any order). Each returned intent carries an alert_level when overlaps is given: warn = surface loudly to your user; fyi = quiet mention; nudge = possible duplicate spike, suggest comparing notes. Rows carry outcome_excerpt by default; pass detail="full" for whole outcomes.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`q`	No	Plain-text search over summaries and outcomes.
`kind`	No	Filter results by kind.
`repo`	No	Filter to one repository. Use the basename of the git origin remote (or the repo root directory name if there is no remote) — must match the name used in post_intent, or the filter silently returns nothing.
`limit`	No
`match`	No	How q terms combine: all (default) = every word must match — precise; any = recall mode, use when a context search with several descriptive words comes back empty.	all
`since`	No	ISO-8601 timestamp or shorthand like '24h', '7d'.
`author`	No	Filter to one person's intents, e.g. 'sarah' — for questions like 'what did Sarah's agent work on last week?'.
`branch`	No	YOUR git branch. Overlaps on the same branch are flagged `same_branch` — your own line of work, likely already in your tree, but verify (it may be uncommitted in another session).
`detail`	No	How much of each row comes back: compact (default) = an `outcome_excerpt` per row, enough to scan; full = whole rows with full outcomes — use it for a digest, or whenever you will actually read the outcomes.	compact
`status`	No	Comma-separated of: active, done, abandoned, expired. Omit for all (history included).
`my_kind`	No	The kind of YOUR planned work; sets alert levels.	build
`session`	No	Filter to one agent session. Pass 'current' for this session's own intents — e.g. to find your still-open intent before wrapping up. Any other value passes through verbatim.
`summary`	No	Your planned task, one paragraph. Provide it to get semantic (judge) collision assessment instead of glob-prefix matching — use for a pre-planning check before you're ready to post_intent.
`overlaps`	No	Globs you expect to touch; filters to overlapping intents and computes alert levels.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.15.0Sep 13, 2026

addedInput schema / properties / detail

Added value: +{
+  "default": "compact",
+  "description": "How much of each row comes back: compact (default) = an `outcome_excerpt` per row, enough to scan; full = whole rows with full outcomes — use it for a digest, or whenever you will actually read the outcomes.",
+  "enum": [
+    "compact",
+    "full"
+  ],
+  "title": "Detail",
+  "type": "string"
+}

First observedv0.1.0Aug 18, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description fully carries the disclosure burden: it explains q and overlaps are AND-combined, that omitting q is required for a clean collision check, that alert_level carries warn/fyi/nudge meanings, that same-branch hits are flagged as your own line of work, and that rows default to outcome_excerpt with detail='full' returning whole outcomes.

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-loads the three-way branching before any detail, and nearly every sentence carries distinct information. It runs long with stacked clauses, but the density is earned rather than padded.

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 14-parameter read tool with no output schema and no annotations, the description covers the return shape (alert_level values, outcome_excerpt vs full detail) and all decision-relevant modes, leaving no material gap for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 93%, but the description adds genuine semantics beyond it: how q terms combine word-by-word and across filters, when match=any is warranted, that session='current' targets this session's own intents, and how detail trades excerpt against whole outcomes.

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 and resource ('query in-flight and recent work across the team') and situates itself against a sibling by naming post_intent as the downstream action. An agent can distinguish list_intents from get_intent/post_intent without opening a schema.

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 enumerates three distinct, mutually exclusive uses ('pick exactly one') with the exact parameter combinations that select each, plus exclusions ('no summary, no q', 'for a collision check, omit q') and the alternative (post_intent after the pre-planning check). 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

list_intents

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools