Skip to main content
Glama

kb_review

Read-only

Review ranked knowledge-base issues with concepts, evidence, and suggested actions; dismiss a kind by adding lint_ignore to a named concept.

Instructions

Ranked kb-doctor work list: items {kind, concepts, evidence, suggested_action}. Dismiss: lint_ignore: [kind] on a named concept.

Input Schema

NameRequiredDescriptionDefault
kindNo
limitNo
scopeNo
offsetNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.1/5.0
Behavior2/5

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

Annotations declare readOnlyHint=true and idempotentHint=false, so the read-only nature is already covered. The description adds an item field list, but the 'Dismiss' clause is cryptic — it is unclear whether this tool performs the dismissal or merely documents the lint_ignore convention, which is exactly the kind of ambiguity an agent needs resolved. No pagination or ordering behavior is explained.

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?

Very short, but terse to the point of being cryptic: two sentence fragments with no subject, and 'kb-doctor' and the Dismiss clause are unexplained. Brevity here reflects under-specification rather than efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, no enum hints, and 0% schema coverage, so the description must carry the burden — yet it omits what the ranking means, how paging works, and what Dismiss actually does. For a four-parameter tool with no required fields this is inadequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for all four parameters (kind, limit, scope, offset). The description only loosely gestures at 'kind' (as an item field and inside lint_ignore) and never mentions limit, offset, or scope, so the parameters remain effectively undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Ranked kb-doctor work list" names a resource and a ranking behavior, and the item shape {kind, concepts, evidence, suggested_action} is disclosed. But it never states what this tool does in plain terms (return a prioritized list of kb issues?) and doesn't distinguish itself from siblings like work_list, lint, or kb_repair.

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

Usage Guidelines2/5

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

No guidance on when to call this versus work_list, lint, or kb_repair. The only procedural note is about dismissing items, which is a downstream action rather than a use case for invoking this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.