F
licenseNot graded
qualityD
maintenanceA local-first MCP server that builds compact voice profiles from writing samples, then compares, rewrites, or generates new text in that voice.
style-memory-mcp
Officialstyle-memory-mcp
Un pequeño servidor MCP local que aprende el estilo conversacional de un usuario, sus muletillas, marcadores dialectales, hábitos de emojis, preferencias de tono y preferencias concretas de colaboración sin almacenar recuerdos privados.
Está diseñado para recordar el sabor de cómo habla alguien, no los datos privados de su vida.
Por qué
La mayoría de las herramientas de memoria de agentes recuerdan hechos:
"El usuario vive en..."
"El usuario trabaja en..."
"El usuario prefiere..."
style-memory-mcp recuerda la voz:
"El usuario dice
lol,no capoship itde manera informal.""Al usuario le gustan las respuestas cálidas y divertidas."
"El usuario usa emojis como
✨,😭o😄.""El usuario utiliza pequeños marcadores idiolectales como
tiny but mighty."
Cosa pequeña. Gran ambiente. ✨
Related MCP server: AI Diary MCP Server
Características
Solo almacenamiento local en JSON — tus datos permanecen en tu máquina
Sin servicio en la nube, sin telemetría, sin llamadas a API externas
El propio servidor MCP nunca llama a un LLM. La ruta del diccionario es pura regex. Opcionalmente, puedes dejar que el agente anfitrión reenvíe sus propias observaciones a través de
hints— consulta Aprendizaje asistido por LLM más abajo.Sin almacenamiento completo del registro de conversación — solo señales de estilo (y un breve ejemplo de uso ≤60 caracteres por hábito, sanitizado antes del almacenamiento)
Primero aprende candidatos; los patrones de expresión semántica necesitan al menos 2 observaciones en 2 sesiones independientes antes de la activación automática
Limpia automáticamente hábitos obsoletos (candidato → archivado → eliminado)
Soporta jerga inglesa, emojis, marcadores multilingües y emoticonos de texto — además de
idiolectde formato libre para cualquier cosa que el LLM anfitrión noteEl diccionario incorporado cubre marcadores de sichuanés, cantonés, noreste (Dongbei), shanghainés y min nan / taiwanés, además de jerga actual (2024–2026) china e inglesa de internet. Etiquetado por localidad para que el agente pueda distinguir frases universalmente seguras de la jerga que debe mantenerse fuera de respuestas legales, médicas o serias.
Devuelve un resumen de estilo accionable: primero cómo aplicar el estilo, luego los hábitos relevantes al contexto
Soporta un
perfil de interacción: cómo prefiere el usuario que el agente colabore, sin etiquetas de personalidadLas preferencias del perfil de interacción pueden revisarse, fijarse u olvidarse al igual que los hábitos de estilo
Incluye una verificación de estado ligera
get_style_memory_scorepara evaluar preparación, riesgo de deriva, riesgo de sobreimitación y breves recomendaciones de actualizaciónFunciona con cualquier agente compatible con MCP que llame a las herramientas
Fija hábitos para protegerlos de la limpieza automática
Pausa el aprendizaje en cualquier momento con
set_learning_enabledv2 produce un resumen de seis secciones: dirección, voz principal, patrones de expresión, puntuación/emojis, preferencias de acompañante y registro de fallos
Separa la observación
hookexterna al modelo de las políticasfull/event/offdelagent; el tiempo de ejecución predeterminado expone solo tres herramientas compactasUtiliza una revisión de almacenamiento persistente con respuestas de cápsula/delta/ack
Instalación
Instalación local
git clone https://github.com/hexingyuofficial/style-memory-mcp.git
cd style-memory-mcp
npm install
npm run buildInstalación global (opcional)
npm install -g style-memory-mcp
# Then use: style-memory-mcpPara desarrollo local:
npm run devConfiguración del Cliente MCP
Añade a la configuración de tu cliente MCP (por ejemplo, Claude Desktop, Cursor, etc.):
{
"mcpServers": {
"style-memory": {
"command": "node",
"args": ["/absolute/path/to/style-memory-mcp/dist/server.js"]
}
}
}Puedes personalizar la ubicación del almacenamiento 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"
}
}
}
}Consulta docs/INTEGRATION.zh-CN.md para una guía práctica de integración en chino, incluyendo notas de configuración estilo Doubao y el protocolo recomendado de actualización automática del resumen.
Variables de Entorno
Variable | Valor por defecto | Descripción |
|
| Ruta al almacenamiento JSON |
|
| Observaciones de hábito de compatibilidad necesarias antes de la activación; las expresiones semánticas también requieren 2 sesiones independientes |
|
| Días antes de que se eliminen los hábitos candidatos no utilizados |
|
| Días antes de que los hábitos activos se archiven |
|
| Límite de resumen heredado; los límites de expresión/dirección de v2 son más estrictos |
|
| Máximo de caracteres para un ejemplo de uso almacenado |
|
| Establecer en |
| sin establecer | Ruta a un archivo JSON de diccionario de estilo personalizado |
Los diccionarios personalizados pueden ser un array o { "habits": [...] }:
{
"habits": [
{
"kind": "catchphrase",
"text": "ship it",
"locale": "en",
"confidenceDelta": 0.14,
"useWhen": ["casual_chat"],
"avoidWhen": ["formal_writing", "high_stakes_advice"],
"match": "word"
}
]
}Herramientas
La conexión de chat predeterminada expone exactamente tres herramientas en tiempo de ejecución:
bootstrap_style_memory: inicia una sesión y devuelvechannel,policy,revision, la primera cápsula y el estado de inicialización único.observe_style_event: envía solo el último mensaje del usuario más sugerencias compactas. Devuelve un acuse de recibo, no el almacenamiento.get_style_brief: devuelve una cápsula en el primer uso, un delta corto después de un cambio de revisión, o un acuse de recibo cuando la revisión conocida está actualizada.
El tiempo de ejecución tiene dos canales de observación. Un hook anfitrión observa cada mensaje
fuera del bucle de herramientas del modelo. Sin un hook, agent usa full durante la medición
precisa de arranque en frío, event después de que la memoria madura, o off para reutilización
de solo lectura. bootstrap_style_memory informa el canal y la política seleccionados.
Establece STYLE_MEMORY_TOOLSET=admin solo para gestión y diagnóstico. La
superficie solo para administración incluye la herramienta de compatibilidad observe_user_message, salida de resumen estructurado completo, herramientas de listado/revisión/fijación/olvido, gestión de direcciones, gestión de registro de fallos, puntuación, estado y distill_recent_style.
En un almacenamiento vacío nuevo, bootstrap solicita inicialización única. Un
anfitrión capaz puede inspeccionar como máximo 12 sesiones locales del anfitrión de los últimos 30 días, luego llamar a bootstrap
nuevamente solo con voz acotada, preferencias de respuesta explícitamente admitidas, preferencias de colaboración concretas y hasta 3 candidatos de expresión. Los mensajes sin procesar, títulos de sesión, campos de identidad/dirección, reglas de fallo y campos desconocidos son rechazados. Si el historial no está disponible, el anfitrión envía action: "skip"; la elección persiste.
distill_recent_style acepta como máximo 3 candidatos cualitativos por llamada. Cada
candidato contribuye con una observación de bajo peso y sigue sujeto a la
puerta de activación de 2 observaciones/2 sesiones; nunca cuenta en masa ni activa
inmediatamente un patrón de expresión. Esto es independiente de la destilación explícita del perfil,
que registra preferencias de colaboración revisadas.
Instrucción para el Agente
Añade algo como esto a tu agente o habilidad:
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.Una plantilla más larga se encuentra en examples/agent-instruction.md.
Perfil de Interacción
style-memory-mcp no construye un perfil de personalidad. Puede aprender
preferencias de colaboración concretas y conductuales que son más seguras y
útiles:
"El usuario prefiere conclusiones antes que detalles."
"Para trabajo técnico, al usuario le gusta planificar → implementar → verificar."
"El usuario prefiere un juicio de valor antes que instrucciones paso a paso."
"Al usuario no le gustan los elogios vagos y quiere recomendaciones específicas."
No almacenar:
"El usuario es ansioso."
"El usuario es introvertido."
Etiquetas psicológicas, diagnósticos o tipos de personalidad.
Identidad del mundo real, dirección, trabajo u otros datos privados.
Los agentes anfitriones pueden enviar profileHints en observe_style_event (o la herramienta
de compatibilidad de administración):
{
"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
}
]
}Para una siembra única, usa distill_interaction_profile con 1–8
preferencias de alta convicción. Las preferencias activas del perfil aparecen en
get_style_brief junto con los hábitos de estilo, pero el resumen se mantiene breve y
filtrado por contexto.
Si una preferencia del perfil es incorrecta, usa forget_interaction_preference. Si es
importante y debe sobrevivir a la limpieza, usa pin_interaction_preference.
Usa review_interaction_profile para una cola de corrección breve.
Deriva y Actualización
El servidor MCP no puede insertar contexto en el agente anfitrión por sí mismo. Una
configuración MCP persistente, una ruta STYLE_MEMORY_PATH absoluta fija y una instrucción
global del agente deben hacer que el anfitrión inicie cada nueva sesión. El
anfitrión debe actualizar su resumen de alineación:
al inicio de un nuevo chat,
no antes de cada 30 turnos de usuario como respaldo para chats largos,
después de cambios importantes de tema o contexto,
antes de respuestas largas o importantes,
cuando el usuario dice "esto no se siente bien", "realíneate con mi estilo", "eso no suena como yo" o similar.
Para una verificación de estado rápida, llama a get_style_memory_score. Si
briefRefreshRecommended es true, llama a get_style_brief antes de la siguiente
respuesta sustancial.
Reutilización de Solo Lectura y Reinicios
Los procesos MCP normalmente son iniciados y reiniciados por el agente anfitrión.
style-memory-mcp no necesita reiniciarse por sí mismo. La parte duradera es el
almacenamiento JSON: si varias conversaciones usan la misma STYLE_MEMORY_PATH, leen
la misma memoria de estilo después de cualquier reinicio.
Si el almacenamiento ha aprendido lo suficiente y quieres que guíe el estilo sin seguir aprendiendo, usa este patrón:
Mantén la misma
STYLE_MEMORY_PATH.Llama a
get_style_briefal inicio de una nueva conversación.Llama a
set_learning_enabled(false)o estableceSTYLE_MEMORY_LEARNING=off.Vuelve a activar el aprendizaje solo cuando quieras actualizar el estilo.
Esto te da una transferencia de estilo persistente sin escribir nuevos hábitos en cada mensaje.
Aprendizaje Asistido por LLM
La ruta del diccionario solo conoce lo que está codificado (jerga de internet, muletillas comunes, emojis, marcadores regionales, etc.). Se perderá cualquier cosa que el autor no haya considerado, incluidos los hábitos personales que hacen que alguien suene como él mismo.
style-memory-mcp resuelve esto sin asumir una dependencia de LLM:
el agente anfitrión ya lee cada mensaje del usuario para generar su respuesta, así que
deja que pase cualquier cosa que haya notado. El servidor MCP sigue siendo una capa
delgada de "contador + ciclo de vida + seguridad" sobre JSON local. Sin clave API. Sin
red. Sin registro de modelos. Coste adicional cero.
// 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
}
]
}Después de dos observaciones semánticas en dos valores distintos de sessionId,
tiny but mighty se promociona a active y puede aparecer en resúmenes futuros.
El MCP aplica la puntuación y la puerta de activación; una sugerencia de confianza del anfitrión no reemplaza
las observaciones requeridas.
Para la destilación al final de la sesión, llama a la herramienta solo para administración distill_recent_style con
como máximo 3 candidatos de bajo peso. Cada llamada está acotada y no evita la
puerta de activación.
Barreras de seguridad que hacen esto seguro:
El propio servidor MCP nunca llama a un LLM — solo registra lo que el anfitrión informó. "Sin red" sigue siendo cierto.
Las sugerencias con un
kindincorrecto otextvacío se descartan, no se aprenden.Los ejemplos se sanitizan (
sanitizeExample): colapso de espacios en blanco, límite de longitud, contenido sensible (credenciales/tokens) se descarta silenciosamente.La regla de promoción de dos observaciones + dos sesiones evita que una única sugerencia alucinada contamine el conjunto de hábitos activos.
Todos los controles existentes (
forget_style_habit,pin_style_habit,set_learning_enabled) funcionan sin cambios.
Reglas de Limpieza
El servidor no necesita un demonio en segundo plano. La limpieza ocurre cuando el MCP se inicia y cuando se llaman a las herramientas.
Comportamiento predeterminado:
Los hábitos candidatos desaparecen después de 30 días de inactividad.
Los hábitos activos se archivan tras 180 días de inactividad.
Los hábitos archivados se eliminan después de 360 días desde su última aparición.
Los patrones de expresión fijados nunca se eliminan automáticamente.
Las direcciones, las preferencias explícitas de acompañante y el registro de fallos no son olvidados por la limpieza TTL de patrones de expresión.
forgetes inmediato.
Importante: un hábito se refresca solo cuando el usuario lo vuelve a decir. El uso del agente no lo mantiene vivo, por lo que el sistema no se queda imitándose a sí mismo.
Ejemplo de 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"]
}Actualización y reversión
Para una instalación existente, construye el paquete y ejecuta
node scripts/install-or-upgrade.mjs a través de un envoltorio específico del host que
proporcione una raíz de instalación explícita y la misma ruta absoluta del almacén. El
instalador prepara un runtime versionado, realiza una copia de seguridad del almacén v1 y de los archivos del host,
migra el almacén de forma atómica, cambia a un lanzador estable y realiza un
apretón de manos runtime/almacén-versión. Un bloqueo hace que las ejecuciones concurrentes fallen de forma segura;
los fallos devuelven un resultado de reversión legible por máquina y restauran el antiguo runtime,
almacén y configuración del host.
El instalador no escanea ni modifica rutas arbitrarias. Mantén el lanzador,
la configuración de MCP, la instrucción global del agente y STYLE_MEMORY_PATH estables
entre sesiones para que cada nueva sesión pueda arrancar el mismo almacén.
Desarrollo
El backlog de endurecimiento v0.5.0, el modelo de memoria, los experimentos reproducibles y la puerta de lanzamiento
se siguen en
docs/V0.5.0-HARDENING-PLAN.zh-CN.md.
El hito solo se completa después de que cada experimento requerido pase.
La secuencia de ejecución detallada y el prompt de transferencia están en
docs/V0.5.0-EXECUTION-PLAN.zh-CN.md
y 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 devTamaño del diccionario y coste de tokens
El diccionario integrado (marcadores de dialecto, muletillas, jerga de internet)
reside en src/extract.ts y nunca se envía al LLM. Solo
participa en escaneos locales de text.includes() / regex. Duplicar el
diccionario cuesta cero tokens adicionales por turno.
Las cargas útiles que llegan al LLM anfitrión incluyen:
La primera cápsula y los deltas posteriores. El resumen v2 tiene seis secciones ordenadas: dirección, voz principal, patrones de expresión, puntuación/emoji, preferencias de acompañante y registro de fallos. La salida típica selecciona una dirección por dirección y dos patrones de expresión; los límites estrictos son dos direcciones por dirección y cinco patrones de expresión.
Descripciones de herramientas, esquemas, parámetros de llamada y retornos de herramientas. El runtime expone solo tres esquemas compactos; los esquemas de administración son opt-in.
La cápsula permanece en las entradas posteriores del modelo y debe ser contada de nuevo por un informe
real de uso de tokens. Un acuse de revisión no añade otra copia. El proyecto
no reclama un resultado de token de modelo E06 cuando no hay un tokenizador objetivo o un uso de API de modelo
disponible; ver docs/V0.5.0-TOKEN-REPORT.zh-CN.md.
Así que si tu dialecto o jerga no está cubierto, por favor envía un PR con nuevas entradas — solo mejora el recuerdo y no inflará los prompts de nadie.
Privacidad
Este proyecto es intencionadamente aburrido con los datos:
Almacena señales de estilo, no mensajes en bruto.
Evita aprender de contextos obviamente secretos (los patrones similares a credenciales se filtran).
Mantiene su propio almacén JSON, separado de cualquier base de datos de memoria del usuario.
Los usuarios pueden listar, olvidar, fijar o deshabilitar el aprendizaje en cualquier momento.
Sin llamadas de red. Todo se ejecuta localmente.
Contribuciones
¡Las contribuciones son bienvenidas! Especialmente:
Nuevos patrones de jerga, emoji o expresión regional
Nuevos patrones de muletillas para cualquier idioma
Mejores heurísticas para la detección de sensibilidad
Mejoras de rendimiento
Por favor, añade pruebas para nuevas reglas de extracción. Mira src/extract.test.ts para ejemplos.
Licencia
MIT
Available Tools
15 toolsdistill_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 | Default |
|---|---|---|---|
| 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.
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
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Cloud-hosted MCP server for durable AI memory
MCP server for AI dialogue using various LLM models via AceDataCloud
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Personal MCP server for humans who create. Proof of authorship, license control.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceA 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.MIT
- AlicenseAqualityBmaintenanceA local, user-owned memory MCP server that allows AI agents to share context via a SQLite file you own.4MIT
- FlicenseBqualityBmaintenanceMCP 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.141
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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