Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

needfix_list

Read-only

List repo-scoped NeedFix entries in compact form, filtered by status, severity, kind, or query and paged for review.

Instructions

List repo-scoped NeedFix entries (bounded); rows are a compact projection.

Measured: 379 rows were 452 KB, about 1.2 KB each (NF-2026-01722, NF-2026-01726). By default each row keeps only id, title, status, severity, kind, converted_task_id and updated_at; full=true or needfix_show returns the full row, which on the derived listing also carries work_state and linked_card_id/linked_card_status.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "needfix_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
fullNoReturn the raw stored rows instead of the compact projection; default false.
kindNoOnly rows of exactly this kind, e.g. bug or improvement; omit for all kinds. Any filter returns raw rows.
limitNoMaximum rows to return; default 100, clamped to 1-500.
queryNoCase-insensitive substring of the id or title, applied before limit/offset; empty (default) lists everything.
offsetNoRows to skip before the first one returned, for paging; default 0.
statusNoOnly rows with exactly this status, e.g. captured, accepted or archived. Any status, kind or severity filter returns raw rows; omit all three for the derived active listing.
order_byNoSort column, created_at (default) or updated_at; any other value falls back to created_at.created_at
severityNoOnly rows of exactly this severity: critical, high, medium, low or info; omit for all. Any filter returns raw rows.
order_dirNoSort direction, DESC (default, newest first) or ASC; any other value falls back to DESC.DESC
include_archivedNoAlso list archived rows; default false.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.12.98
    • addedInput schema / properties / query
      Added value: +{
+  "default": "",
+  "description": "Case-insensitive substring of the id or title, applied before limit/offset; empty (default) lists everything.",
+  "title": "Query",
+  "type": "string"
+}
  2. Changed1 schema field changedv0.12.69
    • changedInput schema / properties / full / description
      Previous value: -"Return every description and evidence body verbatim instead of folding each to its identity; default false."New value: +"Return the raw stored rows instead of the compact projection; default false."
  3. Changed1 schema field changedv0.12.68
    • addedInput schema / properties / full
      Added value: +{
+  "default": false,
+  "description": "Return every description and evidence body verbatim instead of folding each to its identity; default false.",
+  "title": "Full",
+  "type": "boolean"
+}
  4. Changed8 schema fields changedv0.12.67
    • addedInput schema / properties / include_archived / description
      Added value: +"Also list archived rows; default false."
    • addedInput schema / properties / kind / description
      Added value: +"Only rows of exactly this kind, e.g. bug or improvement; omit for all kinds. Any filter returns raw rows."
    • addedInput schema / properties / limit / description
      Added value: +"Maximum rows to return; default 100, clamped to 1-500."
    • addedInput schema / properties / offset / description
      Added value: +"Rows to skip before the first one returned, for paging; default 0."
    • addedInput schema / properties / order_by / description
      Added value: +"Sort column, created_at (default) or updated_at; any other value falls back to created_at."
    • addedInput schema / properties / order_dir / description
      Added value: +"Sort direction, DESC (default, newest first) or ASC; any other value falls back to DESC."
    • addedInput schema / properties / severity / description
      Added value: +"Only rows of exactly this severity: critical, high, medium, low or info; omit for all. Any filter returns raw rows."
    • addedInput schema / properties / status / description
      Added value: +"Only rows with exactly this status, e.g. captured, accepted or archived. Any status, kind or severity filter returns raw rows; omit all three for the derived active listing."
  5. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds real behavioral context beyond them: the measured payload cost of unbounded listings (379 rows at 452 KB, ~1.2 KB per row) and the exact field set the compact projection returns. It also discloses that filtered results fall back to raw rows that additionally carry work_state and linked_card_id/status, which an agent cannot infer from annotations 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 projection behavior is front-loaded in the first clause and the second sentence explains the escape hatch, which is the right order for an agent deciding whether to call it. The embedded ticket IDs (NF-2026-01722, NF-2026-01726) and exact megabyte figures are supporting trivia that does not earn full space, keeping it below a 5.

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?

With 10 parameters, an output schema, and full annotation coverage, the main ambiguity an agent faces is 'will I get what I need in each row', and the description resolves that directly. Remaining details such as paging mechanics and sort behavior are fully handled by the schema, so nothing material is missing.

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 description coverage is 100%, so every parameter including limit clamping, query semantics, and order fallbacks is already documented. The description adds only marginal parameter meaning beyond that, mainly reinforcing the full=true tradeoff and the compact-vs-raw field difference, so the baseline 3 is appropriate.

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 opening sentence names a specific verb and resource (list repo-scoped NeedFix entries) and flags that results are a bounded compact projection. It also separates itself from needfix_show by naming the sibling as the path to full rows, so an agent can route without opening either schema.

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?

It gives clear routing guidance: use the default compact projection for listing volume, and use full=true or needfix_show when the complete row is required. It does not explicitly rule out use versus aggregating siblings like needfix_count, but the context conditions are stated rather than implied.

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