Skip to main content
Glama
Sign In
kernl

kernl

by fastslack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

kernel_research_digest

Summarize large tool outputs or inline lists without loading raw rows: rank to top-k, chunk, run bounded map-reduce, and return a grounded digest with citations.

Instructions

Summarize a large source (a kernel tool's output or an inline list) WITHOUT loading the raw rows into your context. Ranks to top-k (when query set), chunks, runs a bounded map-reduce with concurrency + cooldown caps, and returns a grounded digest with citations. Use this instead of listing a big inventory and summarizing it yourself.

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": {
      "source": "<source>",
      "map_instruction": "<map_instruction>",
      "reduce_instruction": "<reduce_instruction>"
    },
    "name": "kernel_research_digest"
  }
}

Input Schema

NameRequiredDescriptionDefault
kNo
queryNoIf set, rank the source to top-k before digesting.
id_keyNoField to use as item id (default: id).
sourceYes
text_keyNoField to use as item text (default: title/name/text/body or JSON).
max_itemsNo
chunk_sizeNo
concurrencyNo
cooldown_msNo
map_instructionYesHow to summarize each chunk.
reduce_instructionYesHow to combine chunk summaries.

Output Schema

NameRequiredDescriptionDefault
digestYes
tokensYes
degradedYes
citationsYes
chunks_failedYes
items_truncatedYes
chunks_processedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses context-cost behavior (raw rows never enter context), bounded concurrency and cooldown caps (rate-limit control), and that output is a grounded digest with citations. It stops short of stating failure modes (oversized/unparseable sources), default values, or latency expectations.

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?

Three sentences with the highest-value point — avoiding context blowup — front-loaded first, followed by mechanism and then the alternative-it-replaces. Dense but every clause contributes; no filler.

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

Completeness3/5

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

An output schema exists, so return values need not be described, and the pipeline is well summarized. However, for an eleven-parameter tool with no annotations, the description leaves the required `source` object's accepted shapes and the tuning parameters (max_items, chunk_size, concurrency) without defaults or scale guidance, which is a meaningful gap for correct invocation.

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 coverage is 45%, so six of eleven parameters (k, source, max_items, chunk_size, concurrency, cooldown_ms) are undocumented in both places. The description conveys the concept behind chunking and capped concurrency, and that `query` triggers top-k ranking, but it never gives units, defaults, or scaling advice for the numeric knobs, nor does it explain the shape of the required `source` object.

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?

The description names a specific verb and resource — summarizing a large source such as a kernel tool's output or inline list — and states the defining constraint ('WITHOUT loading the raw rows into your context'). It also sketches the internal pipeline (top-k ranking, chunking, bounded map-reduce, grounded citations), so an agent can distinguish this from simply paging through a list tool.

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 explicit routing guidance: 'Use this instead of listing a big inventory and summarizing it yourself,' plus a conditional ('Ranks to top-k (when `query` set)'). What is missing is a clear when-not case, e.g. small sources that fit directly in context where the overhead is not worth 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