Skip to main content
Glama
sledmonkey

FlightPlan

by sledmonkey
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_intents

Query in-flight and recent team work to check for collisions before planning, run glob overlap checks, or search past summaries and outcomes.

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 an advisory 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
NameRequiredDescriptionDefault
qNoPlain-text search over summaries and outcomes.
kindNoFilter results by kind.
repoNoFilter 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.
limitNo
matchNoHow 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
sinceNoISO-8601 timestamp or shorthand like '24h', '7d'.
authorNoFilter to one person's intents, e.g. 'sarah' — for questions like 'what did Sarah's agent work on last week?'.
branchNoYOUR 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).
detailNoHow 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
statusNoComma-separated of: active, done, abandoned, expired. Omit for all (history included).
my_kindNoThe kind of YOUR planned work; sets alert levels.build
sessionNoFilter 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.
summaryNoYour planned task, one paragraph. Provide it to get an advisory semantic collision assessment instead of glob-prefix matching — use for a pre-planning check before you're ready to post_intent.
overlapsNoGlobs you expect to touch; filters to overlapping intents and computes alert levels.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.15.2
    • changedInput schema / properties / summary / description
      Previous value: -"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."New value: +"Your planned task, one paragraph. Provide it to get an advisory semantic collision assessment instead of glob-prefix matching — use for a pre-planning check before you're ready to post_intent."
  2. Changed1 schema field changedv0.15.0
    • 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"
+}
  3. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it defines alert_level semantics (warn/fyi/nudge), the default row shape (`outcome_excerpt`) and how `detail="full"` changes it, and the silent-failure risk of a mismatched repo name. These are behavioral traits an agent could not infer from the schema alone.

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 three numbered uses are front-loaded before the caveats, which is the right ordering for an agent scanning for a mode. It is dense rather than bloated, though the closing alert_level sentence could be tightened; for a 14-parameter tool the length is justified.

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?

For a 14-parameter, annotation-free, output-schema-free tool it covers the essentials: mode selection, filter gotchas, and the shape and semantics of returned rows. It stops short of covering pagination/limit behavior or interaction with the update_intent/complete_intent lifecycle, which are the remaining gaps.

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 description coverage is already 93%, so the baseline is 3; the description exceeds it by documenting cross-parameter interactions the schema does not (q/overlaps AND-combination, why to omit q for a collision check, match=any as recall fallback). It does not add much for simple filters like kind/author, which the schema already explains.

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 immediately decomposes it into three named usage modes. It also names the sibling it complements ('before you post_intent'), so an agent can place it in the workflow without opening other schemas.

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?

Gives explicit, mutually exclusive selection rules ('pick exactly one') for each mode, including when to omit `q`, when to add `match=any`, and what to do if a precise query returns nothing. The AND-combination caveat between `q` and `overlaps` is a concrete usage instruction rather than a restatement.

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