Gitsu MCP priority filters: find P0 items

Gitsu MCP priority filters let an agent find urgent GitHub Projects items by project field, issue label, or either representation. When P0 might be stored in a Priority column or a label, use list_items with fields: {"Priority":"P0"} and match: "any".

The examples below are MCP tool arguments, not GitHub's browser filter syntax. They read items and do not change their priority. For the browser query language, use the separate GitHub Projects filter syntax reference.

How do I find P0 items when priority might be a field or a label?

Call list_items with the Priority value and match: "any" to accept a matching column value or a label named P0.

{
  "fields": { "Priority": "P0" },
  "match": "any"
}

This is useful when an agent works across boards with different conventions. One board may have a single-select Priority column; another may put P0 on the issue as a repository label. With match: "any", a missing Priority column becomes a label search rather than an unknown-column error.

The tool still needs the right board. Add its real project_id to the arguments when the selection must be explicit. The board selection reference explains where that ID comes from and how discovery works.

How do I query only the Priority column or only labels?

Use fields without match: "any" for a column-only query, and use label for a label-only query.

Multiple field filters combine with AND by default. The last example therefore narrows the result to items satisfying both columns. Use the names that the board actually declares; a team can name those columns differently.

Names and values match case-insensitively. Field matching uses equality against the cell or one of its parts, so P1 does not also match P10. Multi-select values can match an individual option. Title search has a separate purpose: search: "P0" searches the title, not the Priority column or labels.

Why did the agent return no P0 items?

An empty answer can reflect the wrong priority representation or vocabulary, so inspect the board's fields and counts before concluding there is no P0 work.

1. Check the board named at the top of the answer.
2. Call list_fields for that board to inspect its real column names and accepted values.
3. Read the filter counts in the list_items answer. They describe the whole board, including items without a value.
4. Query the correct column, labels, or both, depending on what that evidence shows.

For example, the reference documents a diagnostic shaped like No Priority column · label P0 on 10 of 40 items. This is an illustrative count, not a measurement of your board. It explains why a column-only request would miss the work.

Without match: "any", an unknown column name is refused with the board's real columns. An unmatched value can return the values the column accepts. A board using Urgent, High and Low should be queried with those values instead of an invented P0 option.

How do I include enough detail to check the result?

Use show to add labels or links to the short rows returned by list_items.

{
  "fields": { "Priority": "P0" },
  "match": "any",
  "show": ["labels", "url"]
}

The short answer already includes the item's reference, state, title and filtered columns. Labels help explain how an item matched, and the URL gives a direct path to GitHub. Read a particular item with get_item when its title or detail needs closer inspection.

list_items returns 50 rows by default and accepts a limit up to 200. Check the matched count and any truncation notice before treating the displayed rows as the complete result. A board with more matching items than the limit needs a narrower query; a larger limit is still bounded.

This query vocabulary belongs to Gitsu's MCP server. Its local read path can use board data already on the laptop, while each response identifies the source and age of that answer.