Skip to main content
Glama

shelve

File one new entry on an existing shelf, correct or retire an entry by id, and create a shelf the owner just named. Refuses duplicate or oversized entries with a clear reason.

Instructions

Library lane: files one new entry on an existing shelf, or corrects or retires one by id - never the code lane. Use remember instead for code or how to work, never the owner's own life. On a replica this queues instead of writing ('queued for the main machine' is not an error). Refused, naming the shelves that exist, when none fits, unless new_shelf_named_by_owner repeats the owner's new name - then it is created (refused at the ceiling) and the entry filed on it in one call. Refused on a near-duplicate already there, pointing at it; refused past roughly 600 characters unless one_thing_because names the single thing the entry is. retire (id alone) removes it from the listing and search; library still shows it by number, refused without id, with a title/body/label change, or without retire_because. Replies 'filed ', 'revised ' or 'retired ', or the refusal text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoCORRECT AN ENTRY THAT ALREADY EXISTS instead of filing a new one: its number, as the shelf listing shows it. The fields given replace what is there; the number stays, and the version replaced stays readable. Use this whenever a filed entry turns out wrong, badly worded or missing a label - a second entry saying the same thing better makes a shelf unreadable. Omit it to file something new. Required together with `retire`.
bodyNoThe rest, at any length. Optional. See `title`'s own note on `retire`.
shelfYesAn EXISTING shelf, or the one just named in `new_shelf_named_by_owner` on this same call.
titleNoOne line that stands on its own. This is the index. When correcting an entry (see `id`), leave it empty to keep the title it has. Leave it empty on a `retire` too - retire is refused together with a title, body or label change.
labelsNoOptional labels for filtering inside a shelf. See `title`'s own note on `retire`.
retireNoTake this entry out of the shelf listing and out of search, without deleting it - `library` still returns it whole, marked retired, when asked for by its number. Works only together with `id`, and only alone: refused together with a title, body or label change (one thing per call), and refused without `id`. Requires `retire_because`.
retire_becauseNoRequired together with `retire: true`: why this entry no longer belongs on the shelf, in a real sentence - the same requirement `retract` makes on the code lane, and for the same reason: without it nobody can tell a decision from an accident later. Ignored when retire is not set.
one_thing_becauseNoWHY THIS LONG BODY IS STILL ONE THING - required past the length where an entry is usually several things glued together, ignored below it. Name the single thing it is (e.g. "one pizza dough recipe") in a real sentence. Cannot name it in one? Then it is more than one thing - file separate entries on the same shelf with labels instead. Filler here does not get a pile past the question.
new_shelf_named_by_ownerNoTHE OWNER JUST NAMED A NEW SHELF - repeat that name here exactly as he gave it, and it is created (the shelf ceiling still applies) and this entry filed onto it in the same call. THE GAP THIS CLOSES: creating a shelf used to live only behind the `library` command-line binary's own `shelf-new` - an agent that asked and was answered still had no way to act on the answer, which was a dead end at a new user's very first recipe. Never fill this in on your own judgement or to get past a refusal - only after the owner himself named it. Must match `shelf` on this same call, or the write is refused. Meaningless together with `id`: correcting or retiring an entry never creates a shelf.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv2.3.2
    • changedInput schema / properties / body / description
      Previous value: -"The rest, at any length. Optional."New value: +"The rest, at any length. Optional. See `title`'s own note on `retire`."
    • changedInput schema / properties / id / description
      Previous value: -"CORRECT AN ENTRY THAT ALREADY EXISTS instead of filing a new one: its number, as the shelf\nlisting shows it. The fields given replace what is there; the number stays, and the version\nreplaced stays readable. Use this whenever a filed entry turns out wrong, badly worded or\nmissing a label - a second entry saying the same thing better makes a shelf unreadable. Omit\nit to file something new."New value: +"CORRECT AN ENTRY THAT ALREADY EXISTS instead of filing a new one: its number, as the shelf\nlisting shows it. The fields given replace what is there; the number stays, and the version\nreplaced stays readable. Use this whenever a filed entry turns out wrong, badly worded or\nmissing a label - a second entry saying the same thing better makes a shelf unreadable. Omit\nit to file something new. Required together with `retire`."
    • changedInput schema / properties / labels / description
      Previous value: -"Optional labels for filtering inside a shelf."New value: +"Optional labels for filtering inside a shelf. See `title`'s own note on `retire`."
    • addedInput schema / properties / new_shelf_named_by_owner
      Added value: +{
      +  "default": null,
      +  "description": "THE OWNER JUST NAMED A NEW SHELF - repeat that name here exactly as he gave it, and it is\ncreated (the shelf ceiling still applies) and this entry filed onto it in the same call.\nTHE GAP THIS CLOSES: creating a shelf used to live only behind the `library` command-line\nbinary's own `shelf-new` - an agent that asked and was answered still had no way to act on the\nanswer, which was a dead end at a new user's very first recipe. Never fill this in on your own\njudgement or to get past a refusal - only after the owner himself named it. Must match `shelf`\non this same call, or the write is refused. Meaningless together with `id`: correcting or\nretiring an entry never creates a shelf.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • addedInput schema / properties / retire
      Added value: +{
      +  "default": false,
      +  "description": "Take this entry out of the shelf listing and out of search, without deleting it - `library`\nstill returns it whole, marked retired, when asked for by its number. Works only together\nwith `id`, and only alone: refused together with a title, body or label change (one thing per\ncall), and refused without `id`. Requires `retire_because`.",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / retire_because
      Added value: +{
      +  "default": null,
      +  "description": "Required together with `retire: true`: why this entry no longer belongs on the shelf, in a\nreal sentence - the same requirement `retract` makes on the code lane, and for the same\nreason: without it nobody can tell a decision from an accident later. Ignored when retire is\nnot set.",
      +  "type": [
      +    "string",
      +    "null"
      +  ]
      +}
    • changedInput schema / properties / shelf / description
      Previous value: -"An EXISTING shelf. If none fits, ask the owner - you may not create one."New value: +"An EXISTING shelf, or the one just named in `new_shelf_named_by_owner` on this same call."
    • changedInput schema / properties / title / description
      Previous value: -"One line that stands on its own. This is the index. When correcting an\nentry (see `id`), leave it empty to keep the title it has."New value: +"One line that stands on its own. This is the index. When correcting an entry (see `id`),\nleave it empty to keep the title it has. Leave it empty on a `retire` too - retire is refused\ntogether with a title, body or label change."
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only indicate readOnlyHint=false and destructiveHint=false, but the description adds substantial behavior: replica queuing (not an error), retirement semantics (removed from listing/search but still visible by number), refusal reasons, and exact reply strings. This goes far beyond the annotations and enriches the agent's understanding.

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?

The description is long but each sentence adds value, covering the three operation modes, refusal conditions, replica behavior, and reply formats. It is front-loaded with the primary purpose, though the dense run-on style could be broken into clearer sentences. It earns its length despite being verbose.

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?

Given the tool's complexity (9 parameters, multiple modes, no output schema), the description is remarkably complete: it specifies output reply strings, all refusal conditions, the replica queue caveat, and the interaction between parameters (e.g., retire requires id and retire_because). Nothing an agent needs to call it correctly is missing.

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?

The schema already documents all 9 parameters with 100% coverage, including detailed descriptions for each (e.g., id, title, retire, one_thing_because). The description does not add new parameter-level meaning beyond what the schema provides, but it does reference some parameters in context. Baseline 3 is appropriate given full schema coverage.

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 states a precise verb ('shelve') and resource ('a library entry') and clearly distinguishes itself from the code lane ('never the code lane') and from the sibling 'remember' for code or personal life. It covers the three modes (file new, correct, retire) without ambiguity.

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?

It explicitly directs when to use 'remember' instead for code or how-to-work, and describes refusal conditions (no matching shelf, near-duplicate, length limit) and the special case of creating a new shelf when the owner names it. This leaves no doubt about when this tool is the right choice.

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