Skip to main content
Glama
Sign In
Hermoso

Hermoso

Official
by hermoso-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Tidy the Memory list

tidy_memory
DestructiveIdempotent

Clean up workspace Memory by removing product-behavior notes, phone numbers, and emails, then merging near-duplicate facts into single sentences; preview the proposal first, then confirm to apply.

Instructions

Clean up and consolidate the workspace Memory: drops entries that are about how Hermoso, a tool, a connector or a platform API behaves (product behaviour, not the brand), drops phone numbers and emails, and merges near-duplicate facts into one sentence each. Call with no argument to get the PROPOSAL (what would be removed and merged, with reasons) — nothing changes. Call again with confirm:true to apply it through the same typed writers the app uses (deletes carry tombstones so they stay deleted on every device). One model call, billed at its token cost.

Input Schema

NameRequiredDescriptionDefault
brandNoprofile id/name from list_brands, this call only
confirmNotrue to APPLY the proposal; omit to only see it

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.374
    • changedInput schema / properties / brand / description
      Previous value: -"brand id/name from list_brands, this call only"New value: +"profile id/name from list_brands, this call only"
  2. Changed1 schema field changedv0.1.371
    • addedInput schema / properties / brand
      Added value: +{
+  "description": "brand id/name from list_brands, this call only",
+  "type": "string"
+}
  3. Addedv0.1.193

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds genuinely new behavior: the default call is a non-mutating proposal, deletes carry tombstones so they persist across devices, writes go through the same typed writers as the app, and each invocation is one model call billed at token cost. That is exactly the context an agent needs before performing a destructive operation.

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?

Three dense sentences with the dry-run-then-apply protocol front-loaded and no filler. The nested parentheticals and em-dash clauses make it slightly heavy to scan, but every clause carries real information.

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?

For a destructive, default-safe bulk mutation with two optional params and no output schema, the description covers safety model, persistence guarantees, billing implications, and what the proposal contains (removals and merges with reasons). Nothing essential 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?

Schema description coverage is 100%, so both parameters are already documented (brand as a profile id from list_brands, confirm as the apply flag). The description reinforces confirm's two-mode semantics but says nothing about the brand parameter or its 'this call only' scoping, so it only marginally exceeds the schema.

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 ('Clean up and consolidate the workspace Memory') and immediately enumerates the operations performed: dropping product-behaviour entries, dropping phone numbers/emails, and merging near-duplicate facts. This is clearly distinguishable from siblings like list_memory, remember, and forget, which read or write individual entries.

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?

Gives an explicit two-step invocation protocol: call with no argument for a proposal, call again with confirm:true to apply. That is strong operational guidance. It stops short of 5 because it never explicitly contrasts itself with forget or manual cleanup, nor states when this tool should be avoided.

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