Skip to main content
Glama
Sign In
AIWorkhub

AIWorkhub

by shrec
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

needfix_show

Read-only

Retrieve one NeedFix by ID or up to 25 in a single call, with oversized bodies folded to a summary and optional full-body output.

Instructions

Show one NeedFix by id, or up to 25 in one call; a body over 1 KB folds to its own identity.

Use this for the current fields of one NeedFix, or pass needfix_ids to read several in one call; use needfix_list to find ids or needfix_events for its audit history.

Measured 2026-10-09: 51 calls, avg 4 KB, max 12 KB, almost all of it the description and evidence bodies the filer wrote (NF-2026-01447). Each body whose own canonical bytes exceed core.NEEDFIX_BODY_MAX_BYTES is replaced by {summarized, bytes, length, sha256} so it stays addressable; a smaller body is returned verbatim and full=true returns every byte. With needfix_ids the reply is {items, count} in input order, each row folded the same way; an unknown id is its own row with ok: false and error and never fails the others.

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_show"
  }
}

Input Schema

NameRequiredDescriptionDefault
fullNoReturn every body byte verbatim instead of folding bodies over 1 KB to their identity; default false. Refused with needfix_ids.
needfix_idNoNeedFix id, e.g. NF-2026-01447. Give exactly one of needfix_id and needfix_ids.
needfix_idsNoUp to 25 distinct NeedFix ids, answered as {items, count} in input order.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.12.96
    • changedInput schema / properties / full / description
      Previous value: -"Return every body byte verbatim instead of folding bodies over 1 KB to their identity; default false."New value: +"Return every body byte verbatim instead of folding bodies over 1 KB to their identity; default false. Refused with needfix_ids."
    • addedInput schema / properties / needfix_id / default
      Added value: +""
    • changedInput schema / properties / needfix_id / description
      Previous value: -"NeedFix id, e.g. NF-2026-01447."New value: +"NeedFix id, e.g. NF-2026-01447. Give exactly one of needfix_id and needfix_ids."
    • addedInput schema / properties / needfix_ids
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Up to 25 distinct NeedFix ids, answered as {items, count} in input order.",
+  "title": "Needfix Ids"
+}
    • removedInput schema / required
      Removed value: -[
-  "needfix_id"
-]
  2. Changed2 schema fields changedv0.12.67
    • addedInput schema / properties / full / description
      Added value: +"Return every body byte verbatim instead of folding bodies over 1 KB to their identity; default false."
    • addedInput schema / properties / needfix_id / description
      Added value: +"NeedFix id, e.g. NF-2026-01447."
  3. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description carries real weight: it discloses the 1 KB body-folding rule with the exact replacement object shape, that full=true restores verbatim bytes, that full is refused with needfix_ids, that batch replies are {items, count} in input order, and that an unknown id yields its own ok:false row without failing the batch. These are non-obvious behaviors an agent cannot infer from annotations or schema.

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-loaded summary sentence followed by usage routing then behavior, which is the right order. The measurement paragraph (call counts, avg/max size, a cited ticket id) is slightly padded and the example ticket number is decorative rather than load-bearing.

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?

There is no output schema, and the description compensates fully by specifying reply envelopes for both modes and per-row error semantics. Nothing needed to call it correctly or interpret the response is missing.

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 coverage is 100%, so the baseline is 3; the description earns a step up by explaining the folding threshold rationale, the 25-id cap consequence on response ordering, and the full/needfix_ids incompatibility in operational terms. It does not add units or format detail for needfix_id beyond the schema's own example.

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?

Opens with a specific verb and resource ("Show one NeedFix by id, or up to 25 in one call") and immediately distinguishes it from needfix_list (id discovery) and needfix_events (audit history). An agent can tell exactly what this returns without opening the 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 routes: use this for current fields of one or many NeedFixes, use needfix_list to find ids, use needfix_events for history. The single-vs-batch condition is stated with the parameter that selects 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