Skip to main content
Glama

user_storage_manage_by_name_put

Creates or updates a storage entry under the specified key. Use it to write text data to user storage; set confirm:true to apply the mutation.

Instructions

PUT /storage/manage/{name} Создать данные в хранилище Тег: Хранилище Спека: user

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNoТело запроса (text/plain)
nameYesимя ключа
confirmNoЯвное подтверждение выполнения не-GET операции. Без confirm:true в режиме rw возвращается превью запроса.
user_idNoadmin acts on behalf of this user

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.5/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, and it delivers almost nothing: it implies a write/mutation but says nothing about permissions, overwrite/replace semantics for an existing key, or the preview-vs-execute behavior tied to confirm. The confirm/preview contract appears only in the schema, not the description.

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

Conciseness3/5

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

It is very short and the route is front-loaded, which is good. But three of the four fragments are boilerplate (route line, tag, spec) rather than information that helps invocation, so the brevity reflects under-specification as much as efficiency.

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

Completeness2/5

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

For a 4-parameter mutation tool with no annotations and no output schema, the description is insufficient: it never explains what 'data' is stored, what happens on repeated PUT to the same name, or what the confirm/preview flow means for the caller.

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 description coverage is 100%, so name, body, confirm and user_id are all documented at the schema level; baseline 3 applies. The description adds no extra meaning (e.g., body content type, expected key format) beyond restating the route.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a verb and resource ('Создать данные в хранилище') and echoes the HTTP route PUT /storage/manage/{name}, so the operation is identifiable. However it gives no indication of what kind of data is stored or how this differs from the many near-identical siblings (user_storage_manage_post, user_storage_manage_put, user_storage_manage_by_name_post), so the agent cannot distinguish it without opening the schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no when-to-use or when-not-to-use guidance, and no mention of alternatives such as user_storage_manage_post or the non-by-name variants. The 'Тег' and 'Спека' labels are metadata, not usage guidance.

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

Install Server

Other Tools