Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

aiworkhub_manager_needfix_draft

Read-only

Draft NeedFix candidates from a request's own review evidence, including failing checks and reviewer findings, so you can review and file them with needfix_add.

Instructions

READ-ONLY: draft the NeedFixes one request's own review evidence justifies.

A NeedFix could not be drafted from the evidence that justifies it, so it was retyped. Measured 2026-09-08: of 204 manual filings, 76 had an accept/ reject/status/collect result within the previous 15 calls, 43 carried a 32-hex request id, and 355 of 540 typed identifiers (66%) appeared verbatim in the previous 15 tool results; 453 of 557 stored rows carry a hand-typed evidence dict at p50 549 B. Meanwhile 589 accepted-shape reviewer findings and 1,623 failed-gate payloads became a NeedFix only if someone retyped them, and reviewer cards are archived (1,796 so far), taking every unconverted finding with them.

Everything returned is mechanical: title from the failing check id or the finding summary, kind and severity from the finding category through a fixed map, scope_files from the card's changed paths, evidence from terminal_review.evidence (error, returncode, declared command) plus the finding's own path/line/check_id, evidence_refs from the attempt -artifact manifest reference and this request id, and provenance {origin: server_draft, request_id, verified: false}.

The DESCRIPTION is deliberately empty -- it is your judgement about what to do, not a fact on the card, and this never invents one. Writes nothing: file a candidate with needfix_add once you have written that description. finding_id / check_id narrow the draft to exactly one finding or one failing check.

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": {
      "request_id": "<request_id>"
    },
    "name": "aiworkhub_manager_needfix_draft"
  }
}

Input Schema

NameRequiredDescriptionDefault
check_idNoOptional id of one failing check; narrows the draft to exactly that check. Leave empty to draft every failing check.
finding_idNoOptional id of one reviewer finding; narrows the draft to exactly that finding. Leave empty to draft every finding.
request_idYesId of the launched request whose own review evidence to draft from; an unknown request returns request_not_found.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.12.67
    • addedInput schema / properties / check_id / description
      Added value: +"Optional id of one failing check; narrows the draft to exactly that check. Leave empty to draft every failing check."
    • addedInput schema / properties / finding_id / description
      Added value: +"Optional id of one reviewer finding; narrows the draft to exactly that finding. Leave empty to draft every finding."
    • addedInput schema / properties / request_id / description
      Added value: +"Id of the launched request whose own review evidence to draft from; an unknown request returns request_not_found."
  2. First observedv0.1.0

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds genuinely useful details on top — that every returned field is mechanically derived (title, kind/severity via a fixed map, scope_files, evidence, provenance origin=server_draft/verified=false) and that DESCRIPTION is deliberately empty as a judgement field rather than an omission. These are traits the schema can't express. It loses a point for not saying anything about draft volume — whether an unfiltered call returns a handful of findings or hundreds.

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

Conciseness2/5

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

The one strong framing sentence is followed by two dense paragraphs of provenance statistics — 204 manual filings, 76 with prior accept/reject results, 355 of 540 identifiers, p50 549 B, 1,796 archived reviewer cards. None of this tells an agent how to invoke the tool; it is justification narrative for whoever commissioned it. Removing it would lose nothing operationally and would surface the actionable parts (mechanical fields, needfix_add next step) far earlier.

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?

The description covers the mechanical field derivation in enough detail that the agent knows what it will get without opening the output schema, and it names the required next step. For a read-only draft with a fully documented schema and an output schema, the remaining gap is minor: no statement of how many drafts an unfiltered request_id yields, which matters for an agent deciding whether to narrow.

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% and all three parameters are documented in-schema, so the description's restatement of request_id as 'the launched request whose own review evidence to draft from' and of finding_id/check_id as narrowers adds little. It contributes only the error behavior (unknown request returns request_not_found), which is also already in the schema. Baseline 3 is right when the schema does all the work.

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 line gives a specific verb and resource ('draft the NeedFixes') scoped to 'one request's own review evidence', and the READ-ONLY prefix plus the closing 'Writes nothing: file a candidate with needfix_add' cleanly separates it from the write-side sibling. It stops short of 5 only because 'NeedFix' and the drafting semantics are never defined in-line for an agent that hasn't already met the domain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It does specify the follow-on step ('file a candidate with needfix_add once you have written that description') and the narrowing behavior of finding_id/check_id, which is real guidance. But there is no statement of when to reach for this tool at all — no exclusion against needfix_preview_convert, the dashboard convert-preview tools, or manual capture — so the trigger condition is left to inference. The long statistics paragraph explains why the tool was built, not when to call it.

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