Skip to main content
Glama

Update taste memory

update_user_taste
DestructiveIdempotent

Replace a saved taste-preference section and regenerate TASTE.md to apply a user-requested preference change, keeping other sections intact and syncing the local file and vault mirror.

Instructions

Replace one persisted taste-preference section and regenerate TASTE.md. Use for a user-requested preference change; use get_user_taste to inspect current preferences or get_user_memory for separate personal notes. The supplied Markdown replaces that section verbatim. Regeneration updates the local file and configured vault mirror; other preference sections remain intact.

Input Schema

NameRequiredDescriptionDefault
contentYesReplacement Markdown for the selected taste section; existing text in that section is replaced.
sectionYesTaste-preference section whose saved Markdown body will be replaced.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.12.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and openWorldHint=false; the description adds real context beyond them by disclosing side effects — regeneration writes the local file and the configured vault mirror, while other sections remain intact. It stops short of covering reversibility, failure behavior or permission requirements, so not a 5.

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?

Three tight sentences: what it does, when to use it versus alternatives, then the replacement/regeneration semantics. The most decision-relevant information (the replace-and-regenerate behavior) is front-loaded with no filler.

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?

For a destructive two-parameter write tool with no output schema, the description covers scope of destruction, side-effect destinations and sibling routing, which is close to sufficient. It leaves open what confirmation or result the caller gets after regeneration and whether a bad section/content fails or partially applies.

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 coverage is 100% and the section enum is fully documented, so the baseline is 3. The description's 'supplied Markdown replaces that section verbatim' largely restates what the schema already says ('existing text in that section is replaced'), adding little new meaning.

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?

States a specific verb and resource ('Replace one persisted taste-preference section and regenerate TASTE.md') plus the exact scope of change. It explicitly distinguishes itself from get_user_taste and get_user_memory, so an agent can route correctly without opening schemas.

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?

Gives a positive trigger ('user-requested preference change') and names both alternatives with their distinct purposes ('get_user_taste to inspect current preferences', 'get_user_memory for separate personal notes'). This is explicit when-to-use / when-not-to-use guidance.

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