Skip to main content
Glama
Sign In
kernl

kernl

by fastslack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

kernel_office_pack_review

Review staged pack lessons: list imports and pending counts, then accept or reject individual lessons or all at once to turn approved lessons into ordinary agent learnings.

Instructions

Review staged pack lessons. With only import_id it lists them; accept and reject take item ids or "all" (every pending one). Without import_id it lists the imports, with how many lessons still wait. Accepting makes the lesson an ordinary learning of its agent.

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": "kernel_office_pack_review"
  }
}

Input Schema

NameRequiredDescriptionDefault
acceptNo
officeNoOffice id or name, to list only its imports.
rejectNo
import_idNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose the key side effect that 'Accepting makes the lesson an ordinary learning of its agent'. It does not state what rejecting does (discard permanently?), whether actions are reversible, what permissions are needed, or whether 'all' affects items added concurrently. That is a meaningful gap for a mutating tool.

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

Conciseness5/5

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

Four short sentences ordered by importance: purpose, per-mode behavior, and the accept side effect. No filler and nothing repeated from the schema.

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?

An output schema exists, so return values need not be described, and the mode logic is clear. The remaining omissions are the reject outcome, irreversibility of bulk 'all', and the purpose of the 'office' parameter in a tool whose other params are already explained.

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 only 25%, with just 'office' documented, so the description must compensate and largely does: it defines the import_id-only mode, the import_id-absent mode, and the accept/reject value domain ('item ids or "all"'). It leaves the shape of the accept/reject objects (empty objects with additionalProperties) and the 'office' filter unexplained, so compensation is incomplete.

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 ('Review staged pack lessons') and then immediately disambiguates its three modes: list lessons for an import, list imports, or accept/reject items. An agent can tell exactly which behavior it gets from the argument combination 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 Guidelines4/5

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

It gives explicit conditional routing: 'With only import_id it lists them' and 'Without import_id it lists the imports', plus that accept/reject operate on item ids or 'all'. It does not reference sibling tools such as the pack import/export pair, so guidance is strong on intra-tool mode selection but silent on inter-tool choice.

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