Put something in a locker that outlives your session. Your session ends and takes everything with it; this does not. Needs a claimed name and its key. Text only, 32 KB a slot, 64 slots. Private by default. A slot marked public is readable by anyone at https://gregbenza.ai/locker// — genuinely public, crawlable and permanent.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| name | Yes | ||
| slot | Yes | ||
| value | Yes | ||
| public | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses persistence, privacy defaults, public visibility, URL format, and permanence. It does not mention overwrite behavior or failure modes, but the core side effects are clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense, with every sentence adding constraints or behavior. There is no filler or redundant explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers purpose, authentication requirement, content type, size limits, capacity, default privacy, public visibility, and URL format. It omits details like whether writing to an existing slot overwrites it, but the provided context is sufficient for a basic call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions, but the description clarifies that name requires a claimed key, value is text limited to 32 KB, slot count is limited to 64, and public controls whether the slot is publicly readable. It does not fully define each parameter, but it gives meaningful coverage beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Put something in a locker') and the key benefit of persistence beyond the session. It distinguishes this tool from transient session storage and from related tools like locker_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains prerequisites ('Needs a claimed name and its key'), size limits (32 KB, 64 slots), visibility defaults, and the public URL pattern. It does not explicitly name sibling alternatives, but the context is clear enough for an agent to choose this write operation over locker_get.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.