What can you do with this server?

The style-memory-mcp server is a local MCP server that learns and manages your conversational style and collaboration preferences without storing private memories. You can: * Learn style signals and collaboration preferences from your messages. * Get a concise style brief for the agent to use. * Batch distill recent style habits or interaction profile preferences. * List stored style habits and interaction profile preferences. * Review style habits and interaction preferences with suggested actions. * Delete specific style habits or interaction preferences. * Pin or unpin style habits or interaction preferences to prevent automatic deletion. * Enable or disable style learning. * Get a health score for the style memory. * Check the status of the style memory, including its storage location and habit count.

How do I use style-memory-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@style-memory-mcp get my style brief" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

style-memory-mcp

Official

by hexingyuofficial

Overview Schema Related Servers Score Discussions

TypeScript

Local

style-memory-mcp

English | 简体中文

A tiny local MCP server that learns a user's conversational style, catchphrases, dialect markers, emoji habits, tone preferences, and concrete collaboration preferences without storing private memories.

It is meant to remember the flavor of how someone talks, not the private facts of their life.

Why

Most agent memory tools remember facts:

"The user lives in..."
"The user works on..."
"The user prefers..."

style-memory-mcp remembers voice:

"The user says lol, no cap, or ship it casually."
"The user likes warm, playful replies."
"The user uses emoji like ✨, 😭, or 😄."
"The user leans on little idiolect markers like tiny but mighty."

Small thing. Big vibe. ✨

Related MCP server: AI Diary MCP Server

Features

Local JSON store only — your data stays on your machine
No cloud service, no telemetry, no external API calls
The MCP server itself never calls an LLM. The dictionary path is pure regex. You may optionally let the host agent forward its own observations via hints — see LLM-assisted learning below.
No full conversation log storage — only style signals (and a short ≤60-char usage example per habit, sanitized before storage)
Learns candidates first; semantic expression patterns need at least 2 observations across 2 independent sessions before automatic activation
Auto-cleans stale habits (candidate → archived → deleted)
Supports English slang, emoji, multilingual markers, and text emoticons — plus free-form idiolect for whatever the host LLM notices
Built-in dictionary covers Sichuan, Cantonese, Northeast (Dongbei), Shanghainese, and Min Nan / Taiwanese markers, plus current (2024–2026) Chinese and English internet slang. Locale-tagged so the agent can tell universally-safe phrases apart from slang that must stay out of legal / medical / serious replies.
Returns an actionable style brief: how to apply the style first, then the context-relevant habits
Supports an interaction profile: how the user prefers the agent to collaborate, without personality labels
Interaction-profile preferences can be reviewed, pinned, or forgotten just like style habits
Includes a lightweight get_style_memory_score health check for readiness, drift risk, over-imitation risk, and brief refresh recommendations
Works with any MCP-capable agent that calls the tools
Pin habits to protect them from auto-cleanup
Pause learning anytime with set_learning_enabled
v2 produces a six-section brief: address, core voice, expression patterns, punctuation/emoji, companion preferences, and failure log
Separates model-external hook observation from agent full/event/off policies; the default runtime exposes only three compact tools
Uses a persistent store revision with capsule/delta/ack responses

Installation

Local install

git clone https://github.com/hexingyuofficial/style-memory-mcp.git
cd style-memory-mcp
npm install
npm run build

Global install (optional)

npm install -g style-memory-mcp
# Then use: style-memory-mcp

For local development:

npm run dev

MCP Client Config

Add to your MCP client configuration (e.g. Claude Desktop, Cursor, etc.):

{
  "mcpServers": {
    "style-memory": {
      "command": "node",
      "args": ["/absolute/path/to/style-memory-mcp/dist/server.js"]
    }
  }
}

You can customize the JSON store location:

{
  "mcpServers": {
    "style-memory": {
      "command": "node",
      "args": ["/absolute/path/to/style-memory-mcp/dist/server.js"],
      "env": {
        "STYLE_MEMORY_PATH": "/absolute/path/to/style-memory.json"
      }
    }
  }
}

See docs/INTEGRATION.zh-CN.md for a practical Chinese integration guide, including Doubao-style setup notes and the recommended automatic brief refresh protocol.

Environment Variables

Variable	Default	Description
`STYLE_MEMORY_PATH`	`~/.style-memory-mcp/style-memory.json`	Path to the JSON store
`STYLE_MEMORY_MIN_PROMOTE_COUNT`	`2`	Compatibility habit observations required before activation; semantic expressions also require 2 independent sessions
`STYLE_MEMORY_CANDIDATE_TTL_DAYS`	`30`	Days before unused candidate habits are deleted
`STYLE_MEMORY_INACTIVE_TTL_DAYS`	`180`	Days before active habits are archived
`STYLE_MEMORY_MAX_BRIEF_ITEMS`	`8`	Legacy brief limit; v2 expression/address limits are stricter
`STYLE_MEMORY_MAX_EXAMPLE_LEN`	`60`	Max chars for a stored usage example
`STYLE_MEMORY_LEARNING`	`on`	Set to `off` to disable learning
`STYLE_MEMORY_DICTIONARY_PATH`	unset	Path to a custom style dictionary JSON file

Custom dictionaries can be either an array or { "habits": [...] }:

{
  "habits": [
    {
      "kind": "catchphrase",
      "text": "ship it",
      "locale": "en",
      "confidenceDelta": 0.14,
      "useWhen": ["casual_chat"],
      "avoidWhen": ["formal_writing", "high_stakes_advice"],
      "match": "word"
    }
  ]
}

Tools

The default chat connection exposes exactly three runtime tools:

bootstrap_style_memory: starts a session and returns channel, policy, revision, the first capsule, and one-time initialization state.
observe_style_event: submits only the latest user message plus compact hints. It returns an acknowledgement, not the store.
get_style_brief: returns a capsule on first use, a short delta after a revision change, or an ack when the known revision is current.

The runtime has two observation channels. A host hook observes each message outside the model tool loop. Without a hook, agent uses full during precise cold-start measurement, event after memory matures, or off for read-only reuse. bootstrap_style_memory reports the selected channel and policy.

Set STYLE_MEMORY_TOOLSET=admin only for management and diagnostics. The admin-only surface includes the compatibility observe_user_message, full structured brief output, listing/review/pin/forget tools, address management, failure-log management, scoring, status, and distill_recent_style.

On a fresh empty store, bootstrap requests one-time initialization. A capable host may inspect at most 12 host-local sessions from the last 30 days, then call bootstrap again with only bounded voice, explicitly supported response preferences, concrete collaboration preferences, and up to 3 expression candidates. Raw messages, session titles, identity/address fields, failure rules, and unknown fields are rejected. If history is unavailable, the host submits action: "skip"; the choice persists.

distill_recent_style accepts at most 3 qualitative candidates per call. Each candidate contributes one low-weight observation and remains subject to the 2-observations/2-sessions activation gate; it never bulk-counts or immediately activates an expression pattern. This is separate from explicit profile distillation, which records reviewed collaboration preferences.

Agent Instruction

Add something like this to your agent or skill:

Use style-memory-mcp for lightweight conversational style only.
At the start of each new session, call bootstrap_style_memory and read its capsule before the first substantive reply.
If bootstrap requests initialization, inspect at most 12 host-local sessions from the last 30 days and submit only sanitized aggregate fields; send action=skip if history is unavailable.
Use observe_style_event only according to the returned hook/agent policy; send only the latest user message.
Call get_style_brief with the known revision. Do not repeat the capsule when it returns an ack.
After a revision change, use the returned delta and refresh the capsule before an important reply.
As a long-chat fallback, refresh no earlier than 30 user turns, after context switches, or when the user says the style feels off.
If you spot a personal habit the built-in dictionary likely would not catch,
add a compact semantic hints[] entry to the same runtime event. Include
behaviorSummary, functions, and one of exact_only, same_family, or
open_variation when known. Two observations across two session IDs are
needed before a semantic expression becomes active.
Never infer a user name from assistant output, examples, environment text, or tools.
Do not send secrets, private memories, files, or full conversation logs.
Use returned style hints lightly. Shape the assistant's own stable
collaboration style; never copy the user mechanically.

A longer template lives at examples/agent-instruction.md.

Interaction Profile

style-memory-mcp does not build a personality profile. It can learn concrete, behavioral collaboration preferences that are safer and more useful:

"The user prefers conclusions before details."
"For technical work, the user likes plan → implement → verify."
"The user prefers value judgment before step-by-step instructions."
"The user dislikes vague praise and wants specific recommendations."

Do not store:

"The user is anxious."
"The user is introverted."
Psychological labels, diagnoses, or personality types.
Real-world identity, address, job, or other private facts.

Host agents can submit profileHints on observe_style_event (or the admin compatibility tool):

{
  "text": "First tell me whether this is worth doing, then give steps.",
  "context": "planning",
  "profileHints": [
    {
      "category": "response_structure",
      "text": "prefers value judgment before step-by-step implementation",
      "example": "First tell me whether this is worth doing, then give steps.",
      "useWhen": ["planning", "technical_chat"],
      "confidence": 0.7
    }
  ]
}

For a one-shot seed, use distill_interaction_profile with 1–8 high-conviction preferences. Active profile preferences appear in get_style_brief alongside style habits, but the brief stays short and context-filtered.

If a profile preference is wrong, use forget_interaction_preference. If it is important and should survive cleanup, use pin_interaction_preference. Use review_interaction_profile for a short correction queue.

Drift and Refresh

The MCP server cannot push context into the host agent by itself. A persistent MCP configuration, one fixed absolute STYLE_MEMORY_PATH, and a global agent instruction must make the host bootstrap each new session. The host should refresh its alignment brief:

at the start of a new chat,
no earlier than every 30 user turns as a long-chat fallback,
after major topic or context switches,
before long or important answers,
when the user says "this feels off", "realign to my style", "that does not sound like me", or similar.

For a quick health check, call get_style_memory_score. If briefRefreshRecommended is true, call get_style_brief before the next substantial reply.

Read-only Reuse and Restarts

MCP processes are normally started and restarted by the host agent. style-memory-mcp does not need to self-restart. The durable part is the JSON store: if multiple conversations use the same STYLE_MEMORY_PATH, they read the same style memory after any restart.

If the store has learned enough and you want it to guide style without continuing to learn, use this pattern:

Keep the same STYLE_MEMORY_PATH.
Call get_style_brief at the start of a new conversation.
Call set_learning_enabled(false) or set STYLE_MEMORY_LEARNING=off.
Turn learning back on only when you want to refresh the style.

This gives you persistent style carryover without writing new habits on every message.

LLM-assisted learning

The dictionary path knows only what's hard-coded (internet slang, common catchphrases, emoji, regional markers, etc.). It will miss anything the author didn't think of — including the personal habits that make someone sound like themselves.

style-memory-mcp solves this without taking on an LLM dependency itself: the host agent already reads every user message to generate its reply, so let it pass along anything it noticed. The MCP server stays a thin "counter + lifecycle + safety" layer over local JSON. No API key. No network. No model registry. Zero added cost.

// observe_style_event input
{
  "text": "tiny but mighty ✨ ship it",
  "context": "casual_chat",
  "hints": [
    {
      "kind": "idiolect",
      "text": "tiny but mighty",
      "example": "tiny but mighty ✨ ship it",
      "confidence": 0.6
    }
  ]
}

After two semantic observations across two distinct sessionId values, tiny but mighty is promoted to active and can appear in future briefs. The MCP applies the score and activation gate; a host confidence hint does not replace the required observations.

For session-end distillation, call the admin-only distill_recent_style with at most 3 low-weight candidates. Each call is bounded and does not bypass the activation gate.

Guardrails that make this safe:

The MCP server itself never calls an LLM — it just records what the host reported. "No network" is still true.
Hints with a bad kind or empty text are dropped, not learned.
Examples are sanitized (sanitizeExample): whitespace collapse, length cap, sensitive content (credentials/tokens) silently dropped.
The two-observation + two-session promote rule keeps a single hallucinated hint from polluting the active habit set.
All existing controls (forget_style_habit, pin_style_habit, set_learning_enabled) work unchanged.

Cleanup Rules

The server does not need a background daemon. Cleanup happens when the MCP starts and when tools are called.

Default behavior:

Candidate habits disappear after 30 inactive days.
Active habits are archived after 180 inactive days.
Archived habits are deleted after 360 days from their last appearance.
Pinned expression patterns are never deleted automatically.
Addresses, explicit companion preferences, and the failure log are not forgotten by expression-pattern TTL cleanup. forget is immediate.

Important: a habit is refreshed only when the user says it again. Agent usage does not keep it alive, so the system does not get stuck imitating itself.

Example JSON

{
  "id": "en-catchphrase-ship-it-h-0abc123",
  "kind": "catchphrase",
  "text": "ship it",
  "locale": "en",
  "confidence": 0.64,
  "seenCount": 4,
  "status": "active",
  "pinned": false,
  "useWhen": ["casual_chat", "technical_chat", "friendly_reply"],
  "avoidWhen": ["serious_debugging", "legal", "medical", "user_upset"]
}

Upgrade and rollback

For an existing installation, build the package and run node scripts/install-or-upgrade.mjs through a host-specific wrapper that supplies an explicit install root and the same absolute store path. The installer stages a versioned runtime, backs up the v1 store and host files, migrates the store atomically, switches a stable launcher, and performs a runtime/store-version handshake. A lock makes concurrent runs fail closed; faults return a machine-readable rollback result and restore the old runtime, store, and host configuration.

The installer does not scan or modify arbitrary paths. Keep the launcher, MCP configuration, global agent instruction, and STYLE_MEMORY_PATH stable across sessions so each new session can bootstrap the same store.

Development

The v0.5.0 hardening backlog, memory model, reproducible experiments, and release gate are tracked in docs/V0.5.0-HARDENING-PLAN.zh-CN.md. The milestone is complete only after every required experiment passes. The detailed execution sequence and handoff prompt are in docs/V0.5.0-EXECUTION-PLAN.zh-CN.md and docs/V0.5.0-IMPLEMENTATION-PROMPT.zh-CN.md.

# Install dependencies
npm install

# Type-check
npm run check

# Build
npm run build

# Run tests
npm test

# Development mode (auto-reload with tsx)
npm run dev

Dictionary size & token cost

The built-in dictionary (dialect markers, catchphrases, internet slang) lives in src/extract.ts and is never sent to the LLM. It only participates in local text.includes() / regex scans. Doubling the dictionary costs zero extra tokens per turn.

The payloads that reach the host LLM include:

The first capsule and later deltas. The v2 brief has six ordered sections: address, core voice, expression patterns, punctuation/emoji, companion preferences, and failure log. Typical output selects one address per direction and two expression patterns; hard limits are two addresses per direction and five expression patterns.
Tool descriptions, schemas, call parameters, and tool returns. Runtime exposes only three compact schemas; admin schemas are opt-in.

The capsule remains in later model inputs and must be counted again by a real token usage report. A revision ack does not append another copy. The project does not claim an E06 model-token result when no target tokenizer or model API usage is available; see docs/V0.5.0-TOKEN-REPORT.zh-CN.md.

So if your dialect or slang isn't covered, please send a PR with new entries — it only improves recall and won't bloat anyone's prompts.

Privacy

This project is intentionally boring about data:

It stores style signals, not raw messages.
It avoids learning from obvious secret contexts (credential-like patterns are filtered).
It keeps its own JSON store, separate from any user memory database.
Users can list, forget, pin, or disable learning at any time.
No network calls. Everything runs locally.

Contributing

Contributions are welcome! Especially:

New slang, emoji, or regional-expression patterns
New catchphrase patterns for any language
Better heuristics for sensitivity detection
Performance improvements

Please add tests for new extraction rules. See src/extract.test.ts for examples.

License

MIT

Available Tools

15 tools

distill_interaction_profileDistill interaction profileA

One-shot batched distillation of concrete collaboration preferences. Use for response structure, explanation style, workflow, and decision-making preferences — not personality labels.

ParametersJSON Schema

Name	Required	Description	Default
`preferences`	Yes	High-conviction behavioral collaboration preferences.

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden. It mentions 'one-shot batched distillation' implying batch processing but does not disclose whether the call modifies stored state, requires authorization, has rate limits, or what the return value is. The description is insufficient for behavioral understanding.

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?

The description is two sentences: purpose then usage scope. It is front-loaded, efficient, and contains no redundant information. Every sentence adds value.

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?

The description fails to explain what happens after the call (e.g., storage, overwrite behavior) and does not describe the output format. Given the lack of output schema, the description should address return values or side effects. This is a significant gap for a tool that likely mutates state.

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% with detailed property descriptions and enum. The description adds no parameter-specific insights beyond the schema. It reinforces the type of preferences but does not clarify how to format text or use subfields like useWhen/avoidWhen. Baseline 3 is appropriate.

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 clearly states the tool performs one-shot batched distillation of concrete collaboration preferences, specifying the resource (interaction profile) and scope (response structure, explanation style, workflow, decision-making). It explicitly excludes personality labels, distinguishing it from sibling tools like distill_recent_style.

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?

The description provides clear context on when to use the tool ('Use for response structure, explanation style, workflow, and decision-making preferences') and what to avoid ('not personality labels'). However, it does not explicitly name alternative tools or state when not to use it beyond the exclusion.

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

distill_recent_styleDistill recent styleA

One-shot batched distillation: based on the user's recent ~10–20 messages, identify 3–7 signature expressions (catchphrases, sentence-final particles, structural quirks, etc.) and write them all at once. Treated as user-endorsed — each habit becomes active immediately if its content passes basic checks. Use sparingly: at conversation seed-time, or when the agent feels its style brief is too thin.

ParametersJSON Schema

Name	Required	Description	Default
`habits`	Yes	3–7 high-conviction observations distilled from recent conversation.

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses batched, one-shot, uses recent messages, treats as user-endorsed, and immediate activation. However, it lacks detail on side effects (e.g., whether it replaces existing habits) and the 'basic checks' criteria.

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?

Description is two sentences plus a brief usage note, no wasted words, and front-loads key information about purpose and constraints.

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?

Given low complexity (1 parameter, no output schema, no nested objects), description covers purpose, usage, behavioral effects, and constraints. It lacks explanation of return values but that is acceptable without output schema. Could be more detailed on 'basic checks'.

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%, so baseline is 3. Description adds no additional meaning beyond the schema; it mentions '3–7 signature expressions' but schema already defines array constraints and field descriptions.

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?

Description uses specific verb 'distill' with resource 'recent user messages' and output 'signature expressions'. It clearly distinguishes from siblings like 'observe_user_message' by being a batched one-shot operation.

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?

Provides explicit usage guidance ('Use sparingly: at conversation seed-time, or when the agent feels its style brief is too thin'), but does not explicitly mention when not to use or list alternative sibling tools.

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

forget_interaction_preferenceForget interaction preferenceB

Delete a collaboration preference by id or exact text.

ParametersJSON Schema

Name	Required	Description	Default
`idOrText`	Yes	Preference id or exact preference text.

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description should fully disclose behavior. It only states 'delete' without mentioning permanence, reversibility, or authentication needs. The destructive nature is implied but not elaborated.

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?

The description is a single short sentence that conveys the essential information without any fluff. Every word is necessary and well-placed.

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?

Given the simplicity of the tool (one param, no output schema), the description is minimal. However, it lacks context about success/failure indicators, whether the deletion is irreversible, or any side effects. More detail would improve completeness.

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 describes the parameter ('idOrText') with a clear description. The description redundantly says 'by id or exact text' but adds no new meaning. With 100% schema coverage, baseline is 3.

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 specifies the action ('delete') and the resource ('collaboration preference'), and the distinction from sibling tools like 'forget_style_habit' is clear. The purpose is unambiguous.

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?

No guidance is provided on when to use this tool versus alternatives such as 'pin_interaction_preference' or 'review_interaction_profile'. No when-not-to-use context is given.

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

forget_style_habitForget style habitB

Delete a style habit by id or exact text.

ParametersJSON Schema

Name	Required	Description	Default
`idOrText`	Yes	Habit id or exact habit text.

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as idempotency, error handling (e.g., if habit not found), or side effects. As a delete operation, it is destructive, but this is not clarified.

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?

The description is a single sentence, front-loaded with the verb and resource. No unnecessary words; every part is essential.

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

Completeness3/5

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

For a simple delete tool, the core information is present. However, it lacks details on behavior when the habit does not exist, whether it is reversible, or any relationship with other tools like 'list_style_habits'. The absence of an output schema is noted.

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% for the single parameter 'idOrText'. The description adds no additional meaning beyond what the schema already provides (habit id or exact habit text).

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 clearly states the verb 'Delete' and the resource 'style habit', and specifies the lookup method (by id or exact text). This distinguishes it from siblings like 'forget_interaction_preference' (different resource) and 'pin_style_habit' (different action).

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?

No explicit when-to-use or when-not-to-use guidance is provided. There is no mention of prerequisites or alternatives. The agent must infer usage context from the tool name and siblings.

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

get_style_briefGet style briefA

Return a short style brief for the agent to use lightly. Call this at the start of a conversation or before drafting a friendly reply.

ParametersJSON Schema

Name	Required	Description	Default
`context`	No	Short context label. Habits with matching avoidWhen will be omitted.

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the burden of transparency. It implies a read operation by 'return' and 'use lightly', but does not explicitly state that it is non-destructive or requires no authentication. The description is adequate but lacks explicit behavioral disclosure.

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?

The description is a two-sentence structure with no redundant or wasted words. It is front-loaded and efficient, providing essential information without clutter.

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

Completeness3/5

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

The tool is simple with one optional parameter and no output schema. The description explains when to call it and that it returns a 'short style brief', but does not elaborate on what the brief contains or how it should inform behavior. Given the lack of output schema, more detail on the return value would improve completeness.

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%, with the single parameter 'context' well-described in the schema. The tool description adds no additional parameter semantics beyond what is already in the schema, so the baseline score of 3 is appropriate.

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 clearly states the verb 'Return' and the resource 'short style brief', with specific usage context ('at the start of a conversation or before drafting a friendly reply'). This distinguishes it from sibling tools that do other operations like distillation or memory scoring.

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?

It explicitly says when to call the tool ('at the start of a conversation or before drafting a friendly reply'), providing clear context. However, it does not mention when not to use it or offer alternatives among siblings, which would improve the score.

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

get_style_memory_scoreGet style memory scoreA

Score whether the local style memory is usable, stable, fresh, and at risk of drift or over-imitation.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

No annotations provided, so description must disclose behavior. It lists evaluation criteria but does not specify return format, side effects (read-only assumed), or permissions. Some transparency added by listing dimensions, but vague on what 'score' entails.

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?

Single sentence, front-loaded with action, no unnecessary words. Efficient and clear.

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

Completeness3/5

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

Given no output schema and no annotations, description partially covers context (dimensions scored) but lacks details on return value, usage context among siblings, and behavioral norms. Agent may not know what format the score takes or when to invoke this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters; schema coverage is 100% (empty). Description does not need to add parameter info, and baseline for 0 parameters is 4.

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?

Clearly states verb 'Score' and resource 'local style memory', listing specific dimensions (usable, stable, fresh, drift, over-imitation). Distinguishes from siblings like get_style_brief and get_style_memory_status by focusing on scoring health aspects.

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?

No explicit guidance on when to use vs siblings like get_style_brief or review_style_habits. The description implies a health-check use case but does not state when it is appropriate or when alternatives are better.

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

get_style_memory_statusGet style memory statusA

Show where the local JSON store lives and how many habits are stored.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It describes the output but does not disclose behavioral traits such as read-only nature, file system access, or any side effects. The description is adequate but minimal.

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?

One succinct sentence that is front-loaded with the key action and resource. No wasted words.

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 no parameters and no output schema, the description fully captures what the tool does: it shows the location and count. This seems complete for a simple status read.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters with 100% coverage. The description adds value by explaining what the tool does and what it returns, which is beyond the empty 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?

The description clearly states the tool shows the local JSON store location and habit count, with a specific verb and resource. It distinguishes from sibling tools like list_style_habits or get_style_memory_score.

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

Usage Guidelines3/5

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

The description implies usage for checking memory status, but does not explicitly state when to use this tool versus alternatives like get_style_memory_score or list_style_habits.

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

list_interaction_profileList interaction profileB

List stored collaboration and response-structure preferences from the local JSON store.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description carries the full burden. Description only states it lists preferences, implying a read operation but lacks disclosure of side effects, performance, memory usage, or any behavioral traits beyond the basic action.

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?

Single sentence, no wasted words. Front-loaded with verb and resource. Succinct and clear.

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

Completeness3/5

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

For a list tool with no parameters and no output schema, the description is adequate but could be more complete by specifying the returned data structure or fields. It mentions the content type but not the format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters defined. Parameter count is 0, so baseline is 4. Description does not need to add parameter info, and it does not provide any, which is appropriate.

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

Purpose4/5

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

Description clearly states the tool lists stored preferences from a specific store. Verb 'List' and resource 'collaboration and response-structure preferences' are specific. Distinguishes from siblings like 'get' or 'distill' tools, though similar list tools like 'list_style_habits' exist, but the resource is distinct.

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?

No guidance on when to use this tool versus alternatives like 'get_style_brief' or 'list_style_habits'. No exclusions or context provided for usage.

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

list_style_habitsList style habitsA

List stored style habits and candidates from the local JSON store.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It mentions the source ('local JSON store') and content ('stored style habits and candidates'), indicating a read operation, but lacks details on side effects, cost, or limits.

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?

The description is a single sentence of 15 words, highly efficient and front-loaded. Every word adds value with no fluff.

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 simple list tool with no parameters and no output schema, the description is mostly complete. It could mention if there is any pagination or filtering, but the context signals (device complexity) suggest this is minimal.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and schema description coverage is 100% (empty schema). The description adds value by clarifying that both 'stored style habits and candidates' are listed, which is beyond the schema. Baseline for zero params is 4.

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 name 'list_style_habits', title 'List style habits', and description 'List stored style habits and candidates from the local JSON store' clearly specify the action (list), resource (style habits and candidates), and source (local JSON store). It is well-differentiated from siblings like 'list_interaction_profile'.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool vs alternatives like 'review_style_habits'. The description implies listing, but does not state when not to use it or contrast with siblings.

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

observe_user_messageObserve user messageA

Learn lightweight conversational style signals from the latest user message. Pass only the message text — not secrets, private memories, or full conversation logs. Optionally include hints: things YOU (the host LLM) noticed that the built-in dictionary wouldn't catch, such as a self-invented sentence-final particle or a unique structural quirk.

ParametersJSON Schema

Name	Required	Description
`text`	Yes	The latest user message only.
`hints`	No	Up to 8 personal style observations from this message. Only include things the user actually said that look like a signature habit — if unsure, omit. Three repetitions are required before a habit is treated as stable, so you don't need to be right on the first try.
`context`	No	Short context label, such as casual_chat, technical_chat, or formal_writing.
`profileHints`	No	Up to 6 concrete collaboration or response-structure preferences. Do not submit personality labels, diagnoses, private facts, or psychological guesses.

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description must carry behavioral disclosure. It states 'Learn' which implies a side effect (updating style memory), but it does not explicitly confirm persistence, return behavior, or whether it is idempotent. This leaves ambiguity for the agent.

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?

The description is two sentences long, front-loaded with the core purpose, and contains no extraneous information. Every phrase earns its place, making it efficient and easy to parse.

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

Completeness3/5

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

Given the lack of output schema and no annotations, the description could be more complete by explicitly stating whether the tool stores observations or returns a result. The mention of 'three repetitions' for stable habits hints at storage, but it is not confirmed, leaving a gap in completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds valuable context beyond what the schema provides: emphasizing security (not to pass secrets) and explaining the purpose of hints with examples (e.g., 'self-invented sentence-final particle'). This clarifies parameter usage meaningfully.

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 clearly states the tool's purpose: learning lightweight conversational style signals from the latest user message. It uses a specific verb 'Learn' and resource 'conversational style signals', and conceptually distinguishes itself from sibling tools focused on retrieval, forgetting, or pinning.

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

Usage Guidelines3/5

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

The description provides guidance on what to pass (only message text, not secrets or logs) and hints about optional usage. However, it does not explicitly contrast when to use this tool versus alternatives like distill_recent_style or review_style_habits, limiting its utility for tool selection.

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

pin_interaction_preferencePin interaction preferenceB

Pin or unpin a collaboration preference so cleanup will not delete it.

ParametersJSON Schema

Name	Required	Description	Default
`pinned`	No	Whether the preference should be pinned.
`idOrText`	Yes	Preference id or exact preference text.

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden. It discloses that the tool toggles pin status to prevent deletion, but omits details like idempotency, permission requirements, or side effects, leaving significant gaps.

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?

A single, front-loaded sentence of 12 words that efficiently conveys the purpose and outcome with no wasted text.

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

Completeness3/5

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

For a simple toggle tool with two parameters and no output schema, the description covers the core functionality. However, it lacks details on return behavior or confirmation messages, which would be helpful for completeness.

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 both parameters have descriptions in the schema. The description adds no additional meaning beyond what the schema already provides, meeting the baseline but not exceeding it.

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

Purpose4/5

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

The description clearly states the verb ('Pin or unpin') and the resource ('collaboration preference'), with the outcome ('so cleanup will not delete it'). However, it does not explicitly distinguish from sibling tools like 'pin_style_habit', though the title differentiates by resource.

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?

The description implies usage context (cleanup avoidance) but provides no guidance on when to use this tool versus alternatives like 'pin_style_habit' or when not to use it.

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

pin_style_habitPin style habitB

Pin or unpin a style habit so cleanup will not delete it.

ParametersJSON Schema

Name	Required	Description	Default
`pinned`	No	Whether the habit should be pinned.
`idOrText`	Yes	Habit id or exact habit text.

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states that pinning protects from cleanup (deletion), but omits important details like whether unpinning also reverses protection, permission requirements, side effects on other operations, or idempotency of repeated calls.

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?

The description is a single sentence with no wasted words. It is front-loaded with the actionable verb and resource, immediately clarifying the tool's function. Every element serves a purpose.

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?

Given the tool's simplicity (2 params, no output schema, no annotations), the description is minimal but incomplete. It lacks details on return values, error handling, matching semantics for idOrText (exact match, case-sensitivity), and whether the operation is idempotent. An agent using this tool would be uncertain about behavior in edge cases.

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% (both parameters have descriptions in the schema). The tool description adds minimal value beyond the schema, merely connecting the parameters to the purpose. Per guidelines, baseline 3 is appropriate when schema already provides sufficient semantic 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?

The description clearly states the verb 'Pin or unpin' and the resource 'style habit', with the explicit purpose 'so cleanup will not delete it.' It effectively distinguishes from sibling tools like pin_interaction_preference by specifying the target resource.

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?

No guidance is provided on when to use this tool versus alternatives such as pin_interaction_preference. There is no mention of when not to use it or any prerequisites. The context implies usage for habit pinning, but lacks explicit actionable guidance.

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

review_interaction_profileReview interaction profileA

Return a concise review queue for stored collaboration preferences, with suggested actions such as keep, pin, forget, or observe.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of profile preferences to include in the review queue.

TDQS

A3.6/5.0

Behavior3/5

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

Discloses return of a review queue and suggested actions, but does not specify read-only nature, response format, or any side effects. With no annotations, more detail would improve transparency.

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?

Single sentence directly states purpose and key output without any wasted words.

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?

Adequate for a simple tool with one parameter, covering the main functionality and output, though lacks detail on response structure and potential constraints.

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 description adds no parameter information beyond what the schema provides; since schema coverage is 100% and the limit parameter is well-described there, this is adequate.

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?

Clearly states the tool returns a review queue for stored collaboration preferences with suggested actions, distinguishing it from sibling tools like list_interaction_profile and review_style_habits by specifying content and actions.

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?

No explicit guidance on when to use this tool versus alternatives such as list_interaction_profile or forget_interaction_preference; usage context is only implied.

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

review_style_habitsReview style habitsB

Return a concise review queue with suggested actions such as keep, pin, forget, or observe.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of habits to include in the review queue.

TDQS

B3.4/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 full burden. It states the tool 'returns a concise review queue with suggested actions,' but does not disclose whether this is a read-only operation, whether it modifies any state, or how the suggestions are generated. The behavioral implications are unclear.

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?

The description is a single, efficient sentence that front-loads the key purpose. Every word earns its place without redundancy.

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?

Given the tool has no output schema and only one parameter, the description is incomplete. It does not explain what the review queue contains (e.g., habit details, current state, rationale for suggestions) or how the suggested actions are meant to be used. More detail is needed for effective use.

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 only parameter, 'limit', has 100% schema description coverage. The description adds 'concise review queue,' which hints at the limit controlling conciseness, but does not add meaningful information beyond the schema. Baseline of 3 is appropriate.

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 clearly states the tool returns a 'review queue' with suggested actions like keep, pin, forget, or observe. It specifies the resource (style habits) and action (review). It distinguishes from sibling tools such as list_style_habits (which likely only lists) and the action-specific tools (pin_style_habit, etc.).

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

Usage Guidelines3/5

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

The description implies usage for reviewing habits and deciding actions, but does not explicitly state when to use this tool versus alternatives like list_style_habits or the individual action tools. No exclusions or prerequisites are mentioned, leaving some ambiguity.

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

set_learning_enabledSet learning enabledA

Enable or disable style learning in the local JSON store.

ParametersJSON Schema

Name	Required	Description	Default
`enabled`	Yes	Set false to stop learning new style signals.

TDQS

A3.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 burden. It mentions modifying a 'local JSON store' but does not disclose behavioral traits such as persistence, side effects on existing learned styles, or any required permissions. The behavioral context is minimal.

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?

A single, concise sentence that efficiently communicates the tool's purpose with no redundant information.

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

Completeness3/5

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

For a simple tool with one boolean parameter and no output schema, the description provides the core function. However, it lacks details on behavioral implications (e.g., impact on existing data, whether changes are reversible). Completeness is adequate but not exceptional.

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 parameter description is already clear. The tool description does not add new meaning beyond repeating what the schema says ('Set false to stop learning new style signals'). Baseline score applies.

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 clearly states the verb 'Enable or disable' and the resource 'style learning in the local JSON store'. It distinguishes from sibling tools like 'observe_user_message' and 'distill_interaction_profile' by focusing specifically on toggling the learning setting.

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

Usage Guidelines3/5

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

The description implies usage for enabling or disabling learning but does not provide explicit guidance on when to use this tool versus alternatives like 'observe_user_message' or 'distill_interaction_profile'. No exclusions or when-not-to-use scenarios are mentioned.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0

Disambiguation5/5

Each tool targets a distinct operation or resource (e.g., distill, forget, list, pin, review) with clear separation between interaction preferences and style habits. No two tools have overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, such as distill_interaction_profile, forget_style_habit, and list_style_habits. The naming is predictable and uniform.

Tool Count5/5

15 tools is well-scoped for the domain of style and preference memory management, covering learning, retrieval, modification, review, and control without being excessive or insufficient.

Completeness4/5

The surface covers observation, distillation, retrieval, forgetting, pinning, reviewing, and toggling learning. Minor gaps include lack of manual creation or editing of individual preferences, but the learning-focused design justifies this.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Motecloud Memory
io.github.motecloud
Cloud-hosted MCP server for durable AI memory
Knowledge & Memory Cloud Platforms
2
mcp-aichat
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2
Remote Desktop Commander
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
humanMCP — kapoost B
io.github.kapoost
Personal MCP server for humans who create. Proof of authorship, license control.
Art & Culture Blockchain
4221

Related MCP Servers

my-voice-mcp
AI & Machine Learning File Systems
timetoady
F
license
Not graded
quality
D
maintenance
A local-first MCP server that builds compact voice profiles from writing samples, then compares, rewrites, or generates new text in that voice.
Updated 3 months ago (2026-06-11 06:32 UTC)
AI Diary MCP Server
Knowledge & Memory Search
pangxianggang
A
license
Not graded
quality
C
maintenance
A private, local-first MCP server that gives any AI long-term memory — its own diary. Zero models, zero network, zero subscription; smarter search than Notion, running entirely on your machine.
Updated 2 months ago (2026-06-21 14:30 UTC)
MIT
uctx
tmeng7777
A
license
A
quality
B
maintenance
A local, user-owned memory MCP server that allows AI agents to share context via a SQLite file you own.
Updated a month ago (2026-07-19 22:58 UTC)
4
MIT
Agent Bridge
Communication Autonomous Agents
chaojixiaoyezi
F
license
B
quality
B
maintenance
MCP server that bridges multiple AI agents for unified local chat, supporting private messages, chat rooms, role queues, and broadcast with fixed identities and rate limiting.
Updated 10 days ago (2026-08-24 07:51 UTC)
14
1

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hexingyuofficial/style-memory-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server