Skip to main content
Glama

einordnen

Classify existing memory entries by knowledge kind, e.g., interface, pitfall, or decision. Undo classification with 'gemischt'.

Instructions

Sets the kind of knowledge for existing entries.

Meant for doing in passing: whatever recall surfaces anyway gets its kind assigned along the way. The backlog doesn't have to be sorted in one sitting.

Args: ids: One or more entry ids, e.g. "376,481". art: Exactly one of: schnittstelle (interface), fallstrick (pitfall), entscheidung (decision), messwert (measurement), arbeitsweise (way of working), verlauf (chronicle). "gemischt" (mixed) undoes the classification.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
artYes
idsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations, the description carries the behavioral burden. It usefully discloses that it operates on existing entries and that 'gemischt' undoes the classification, but it does not cover permissions, overwrite behavior for existing kinds, idempotence, or partial batch failure.

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?

The purpose is front-loaded in the first sentence, followed by concise usage context and an Args section. The wording is efficient and every part supports correct invocation.

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 tool is relatively simple and has an output schema, so return values need not be explained. The description covers purpose, usage, and both required parameters well, though it leaves some mutation edge cases unstated because no annotations are present.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must explain parameters, and it does: 'ids' is one or more entry ids with an example comma-separated format, and 'art' is exactly one of the listed classification values, including 'gemischt' to undo classification.

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 first sentence states a specific verb and resource: it sets the kind of knowledge for existing entries. It is clear enough to distinguish a classification/update operation from siblings like recall or remember, but it does not explicitly name or contrast alternatives.

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?

The description gives clear usage context: it is meant to be done in passing as recall surfaces entries, and the backlog need not be sorted in one sitting. It does not explicitly state when not to use it or name a preferred alternative.

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