ローカルのJSONストアのみ — データはマシン上に留まります
クラウドサービスなし、テレメトリーなし、外部API呼び出しなし
MCPサーバー自体はLLMを呼び出しません。 辞書パスは純粋な正規表現です。ホストエージェントが独自の観察結果を hints 経由で任意に転送することは可能です — 以下の LLM支援学習を参照してください。
完全な会話ログは保存されません — スタイルシグナルのみ（および習慣ごとに最大60文字の短い使用例、保存前にサニタイズされます）
まず候補を学習し、意味表現パターンは自動的にアクティブ化される前に少なくとも2つの独立したセッションで2回の観察が必要です
古くなった習慣を自動的にクリーンアップします（候補 → アーカイブ → 削除）
英語のスラング、絵文字、多言語マーカー、テキスト顔文字に対応 — さらに、ホストLLMが気づいたあらゆるものを自由形式の idiolect で記録可能
組み込み辞書は四川語、広東語、東北語、上海語、閩南語/台湾語のマーカー、および現在（2024–2026年）の中国語・英語のインターネットスラングをカバー。ロケールタグ付きで、エージェントが普遍的に安全なフレーズと、法的/医療/深刻な返信では使用すべきでないスラングを区別できます。
実用的なスタイルブリーフを返します：最初にスタイルの適用方法、次に文脈に関連する習慣
interaction profile をサポート：パーソナリティラベルなしで、ユーザーがエージェントとどのように協力したいか
インタラクションプロファイルの設定は、スタイル習慣と同様に確認、固定、または忘れることができます
準備状況、ドリフトリスク、過剰模倣リスク、および簡易リフレッシュ推奨を確認する軽量の get_style_memory_score ヘルスチェックを含む
MCP対応エージェントでツールを呼び出せるものと連携可能
習慣を固定して自動クリーンアップから保護
set_learning_enabled でいつでも学習を一時停止可能
v2では6セクションのブリーフを生成：宛先、コアボイス、表現パターン、句読点/絵文字、コンパニオンの好み、失敗ログ
モデル外部の hook 観察と agent の full/event/off ポリシーを分離。デフォルトのランタイムは3つのコンパクトなツールのみを公開
永続的なストアリビジョンをカプセル/デルタ/応答確認で使用

インストール

ローカルインストール

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

グローバルインストール（任意）

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

ローカル開発の場合：

npm run dev

MCPクライアント設定

MCPクライアント設定に追加します（例：Claude Desktop、Cursorなど）：

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

JSONストアの場所をカスタマイズできます：

{
  "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"
      }
    }
  }
}

実用的な中国語統合ガイドについては、docs/INTEGRATION.zh-CN.md を参照してください。Doubaoスタイルのセットアップメモと推奨される自動ブリーフリフレッシュプロトコルが含まれています。

環境変数

変数	デフォルト	説明
`STYLE_MEMORY_PATH`	`~/.style-memory-mcp/style-memory.json`	JSONストアへのパス
`STYLE_MEMORY_MIN_PROMOTE_COUNT`	`2`	アクティブ化に必要な互換性習慣の観察回数；意味表現には2つの独立したセッションも必要
`STYLE_MEMORY_CANDIDATE_TTL_DAYS`	`30`	未使用の候補習慣が削除されるまでの日数
`STYLE_MEMORY_INACTIVE_TTL_DAYS`	`180`	アクティブな習慣がアーカイブされるまでの日数
`STYLE_MEMORY_MAX_BRIEF_ITEMS`	`8`	従来のブリーフ制限；v2の表現/宛先の制限はより厳格
`STYLE_MEMORY_MAX_EXAMPLE_LEN`	`60`	保存される使用例の最大文字数
`STYLE_MEMORY_LEARNING`	`on`	`off` に設定すると学習を無効化
`STYLE_MEMORY_DICTIONARY_PATH`	未設定	カスタムスタイル辞書JSONファイルへのパス

カスタム辞書は配列または { "habits": [...] } の形式のいずれかです：

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

ツール

デフォルトのチャット接続では、3つのランタイムツールのみを公開します：

bootstrap_style_memory: セッションを開始し、channel、policy、revision、最初のカプセル、および一回限りの初期化状態を返します。
observe_style_event: 最新のユーザーメッセージとコンパクトなヒントのみを送信します。ストアではなく、応答確認を返します。
get_style_brief: 初回使用時はカプセル、リビジョン変更後は短いデルタ、既知のリビジョンが最新の場合は応答確認を返します。

ランタイムには2つの観察チャンネルがあります。ホスト hook はモデルツールループの外部で各メッセージを観察します。フックがない場合、agent は正確なコールドスタート計測中は full、メモリが成熟した後は event、読み取り専用の再利用では off を使用します。bootstrap_style_memory は選択されたチャンネルとポリシーを報告します。

管理と診断目的でのみ STYLE_MEMORY_TOOLSET=admin を設定してください。管理専用のサーフェスには、互換性のある observe_user_message、完全な構造化ブリーフ出力、リスト表示/レビュー/固定/忘却ツール、宛先管理、失敗ログ管理、スコアリング、ステータス、および distill_recent_style が含まれます。

空の新しいストアでは、ブートストラップが一回限りの初期化を要求します。対応可能なホストは、過去30日間の最大12のホストローカルセッションを検査し、その後、限定されたボイス、明示的にサポートされる応答設定、具体的なコラボレーション設定、および最大3つの表現候補のみで再度ブートストラップを呼び出すことができます。生のメッセージ、セッションタイトル、ID/住所フィールド、失敗ルール、および不明なフィールドは拒否されます。履歴が利用できない場合、ホストは action: "skip" を送信します。この選択は永続します。

distill_recent_style は1回の呼び出しにつき最大3つの定性候補を受け入れます。各候補は1つの低加重観察となり、2観察/2セッションのアクティブ化ゲートの対象となります。大量カウントや即時アクティブ化は行われません。これは明示的なプロファイル蒸留とは別で、レビュー済みのコラボレーション設定を記録します。

エージェント命令

エージェントまたはスキルに以下のようなものを追加してください：

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.

より長いテンプレートは examples/agent-instruction.md にあります。

インタラクションプロファイル

style-memory-mcp はパーソナリティプロファイルを構築しません。より安全で有用な、具体的で行動的なコラボレーション設定を学習できます：

「ユーザーは詳細よりも結論を好みます。」
「技術的な作業では、ユーザーは計画 → 実装 → 検証を好みます。」
「ユーザーはステップバイステップの指示よりも価値判断を好みます。」
「ユーザーは漠然とした賞賛を嫌い、具体的な推奨事項を求めます。」

以下のものは保存しないでください：

「ユーザーは不安です。」
「ユーザーは内向的です。」
心理的ラベル、診断、またはパーソナリティタイプ。
現実世界のID、住所、仕事、またはその他のプライベートな事実。

ホストエージェントは observe_style_event（または管理互換ツール）で profileHints を送信できます：

{
  "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
    }
  ]
}

一回限りのシードには、distill_interaction_profile を1〜8の確信度の高い設定で使用します。アクティブなプロファイル設定は、スタイル習慣とともに get_style_brief に表示されますが、ブリーフは短く文脈フィルタリングされたままです。

プロファイル設定が間違っている場合は、forget_interaction_preference を使用してください。重要でクリーンアップに耐えさせたい場合は、pin_interaction_preference を使用してください。短い修正キューには review_interaction_profile を使用してください。

ドリフトとリフレッシュ

MCPサーバーは単独でホストエージェントにコンテキストをプッシュできません。永続的なMCP設定、1つの固定絶対 STYLE_MEMORY_PATH、およびグローバルエージェント命令により、ホストが新しいセッションごとにブートストラップする必要があります。ホストはアライメントブリーフをリフレッシュする必要があります：

新しいチャットの開始時、
長いチャットのフォールバックとして30ユーザーターンごとより早くはしない、
大きなトピックやコンテキストの切り替え後、
長いまたは重要な回答の前、
ユーザーが「これは違う感じがする」「私のスタイルに再調整して」「それは私らしくない」などと言ったとき。

簡単なヘルスチェックには、get_style_memory_score を呼び出してください。briefRefreshRecommended が true の場合、次の重要な返信の前に get_style_brief を呼び出してください。

読み取り専用の再利用と再起動

MCPプロセスは通常、ホストエージェントによって開始および再起動されます。style-memory-mcp は自己再起動する必要はありません。永続的な部分はJSONストアです：複数の会話が同じ STYLE_MEMORY_PATH を使用する場合、再起動後も同じスタイルメモリを読み取ります。

ストアが十分に学習し、学習を継続せずにスタイルをガイドさせたい場合は、次のパターンを使用してください：

同じ STYLE_MEMORY_PATH を維持します。
新しい会話の開始時に get_style_brief を呼び出します。
set_learning_enabled(false) を呼び出すか、STYLE_MEMORY_LEARNING=off を設定します。
スタイルをリフレッシュしたいときにのみ学習を再度有効にします。

これにより、すべてのメッセージで新しい習慣を書き込むことなく、永続的なスタイルの持ち越しが可能になります。

LLM支援学習

辞書パスはハードコードされたもの（インターネットスラング、一般的な口癖、絵文字、地域マーカーなど）のみを認識します。作者が考えつかなかったもの — 人をその人らしくする個人的な習慣 — は見逃します。

style-memory-mcp は、LLM依存関係自体を引き受けることなくこれを解決します：ホストエージェントはすでに応答を生成するためにすべてのユーザーメッセージを読んでいるので、気づいたことを渡させるだけです。 MCPサーバーはローカルJSON上の薄い「カウンター + ライフサイクル + 安全性」レイヤーとして留まります。APIキーなし。ネットワークなし。モデルレジストリなし。追加コストゼロ。

// 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
    }
  ]
}

2つの異なる sessionId 値にわたる2回の意味観察の後、tiny but mighty は active に昇格し、将来のブリーフに表示される可能性があります。MCPはスコアとアクティブ化ゲートを適用します。ホストの信頼度ヒントが必要な観察を置き換えることはありません。

セッション終了時の蒸留には、最大3つの低加重候補で管理専用の distill_recent_style を呼び出してください。各呼び出しは制限されており、アクティブ化ゲートをバイパスしません。

これを安全にするガードレール：

MCPサーバー自体は決してLLMを呼び出しません — ホストが報告した内容を記録するだけです。「ネットワークなし」は依然として真です。
悪い kind または空の text を持つヒントは、学習されずに破棄されます。
例はサニタイズされます（sanitizeExample）：空白の圧縮、長さ制限、機密コンテンツ（認証情報/トークン）は静かに破棄されます。
2観察 + 2セッションの昇格ルールにより、単一の幻覚ヒントがアクティブな習慣セットを汚染するのを防ぎます。
既存のすべての制御（forget_style_habit、pin_style_habit、set_learning_enabled）は変更なく機能します。

クリーンアップルール

サーバーはバックグラウンドデーモンを必要としません。クリーンアップはMCPの起動時とツールが呼び出されたときに実行されます。

候補の習慣は、非アクティブな状態が30日続くと消失します。
アクティブな習慣は、非アクティブな状態が180日続くとアーカイブされます。
アーカイブされた習慣は、最後に出現してから360日後に削除されます。
固定された表現パターンは自動的に削除されることはありません。
アドレス、明示的なコンパニオンの設定、および障害ログは、表現パターンのTTLクリーンアップによって忘れられることはありません。forgetは即時実行されます。

重要: 習慣は、ユーザーが再度発言した場合にのみ更新されます。エージェントの使用では維持されないため、システムが自分自身を模倣してスタックすることはありません。

例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"]
}

アップグレードとロールバック

既存のインストール環境では、パッケージをビルドし、node scripts/install-or-upgrade.mjsを、明示的なインストールルートと同一の絶対ストアパスを指定するホスト固有のラッパーを通して実行します。インストーラは、バージョン管理されたランタイムをステージングし、v1のストアとホストファイルをバックアップし、ストアをアトミックに移行し、安定したランチャーに切り替え、ランタイム/ストアバージョンのハンドシェイクを実行します。ロックにより、並行実行は安全に失敗します。障害が発生した場合は、マシン可読なロールバック結果が返され、古いランタイム、ストア、ホスト設定が復元されます。

インストーラは任意のパスをスキャンしたり変更したりしません。ランチャー、MCP設定、グローバルエージェント指示、STYLE_MEMORY_PATHをセッション間で安定させ、新しいセッションが同じストアをブートストラップできるようにします。

開発

v0.5.0の堅牢化バックログ、メモリモデル、再現可能な実験、リリースゲートは、 docs/V0.5.0-HARDENING-PLAN.zh-CN.mdで追跡されています。マイルストーンは、必要なすべての実験が合格した後にのみ完了します。詳細な実行シーケンスとハンドオフプロンプトは、 docs/V0.5.0-EXECUTION-PLAN.zh-CN.md および 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

辞書サイズとトークンコスト

組み込み辞書（方言マーカー、キャッチフレーズ、インターネットスラング）は src/extract.tsにあり、決してLLMに送信されません。これはローカルのtext.includes() / 正規表現スキャンにのみ関与します。辞書を2倍にしても、ターンあたりの追加トークンコストはゼロです。

ホストLLMに到達するペイロードは次のとおりです。

最初のカプセルとその後の差分。v2の概要には6つの順序付きセクションがあります：アドレス、コアボイス、表現パターン、句読点/絵文字、コンパニオンの設定、障害ログ。典型的な出力では、方向ごとに1つのアドレスと2つの表現パターンが選択されます。ハードリミットは、方向ごとに2つのアドレスと5つの表現パターンです。
ツールの説明、スキーマ、呼び出しパラメータ、ツールの戻り値。ランタイムは3つのコンパクトなスキーマのみを公開し、管理スキーマはオプトインです。

カプセルは後続のモデル入力にも残り、実際のトークン使用量レポートで再カウントする必要があります。リビジョン承認によって別のコピーが追加されることはありません。このプロジェクトは、対象のトークナイザーやモデルAPIの使用状況が利用できない場合に、E06モデルトークンの結果を主張しません。docs/V0.5.0-TOKEN-REPORT.zh-CN.mdを参照してください。

そのため、お使いの方言やスラングがカバーされていない場合は、新しいエントリを含むプルリクエストをお送りください。これにより、再現性が向上し、誰かのプロンプトが肥大化することはありません。

プライバシー

このプロジェクトは、データに関して意図的に控えめです。

スタイルシグナルを保存し、生のメッセージは保存しません。
明らかに機密性の高いコンテキスト（資格情報のようなパターンはフィルタリングされます）から学習することを避けます。
ユーザーのメモリデータベースとは別に、独自のJSONストアを保持します。
ユーザーはいつでも学習を一覧表示、忘却、固定、または無効にすることができます。
ネットワーク呼び出しはありません。すべてローカルで実行されます。

コントリビューション

コントリビューションを歓迎します！特に以下のものです。

新しいスラング、絵文字、または地域表現パターン
任意の言語の新しいキャッチフレーズパターン
感度検出のためのより良いヒューリスティック
パフォーマンスの改善

新しい抽出ルールにはテストを追加してください。例についてはsrc/extract.test.tsを参照してください。

ライセンス

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