Skip to main content
Glama
ashlesh-t

CogniRepo

by ashlesh-t
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

record_user_preference

Store explicit user preferences and query-rewrite corrections in persistent memory so future interactions honor clarified intent and improve retrieval accuracy across sessions.

Instructions

Store an explicit user preference or query-rewrite correction.

Standard preferences (preference_key = any label): Store as: record_user_preference("response_format", "code-first, then explanation") Surfaced via get_user_profile()['explicit_preferences'].

Query-rewrite corrections (preference_key = "query_rewrite"): Use when you asked for X but user says they actually meant Y. Store the wrong phrasing as preference_value, intent in context: record_user_preference("query_rewrite", "deploy model", context="user means: update the ML model weights in production, not software deploy") Stored in query_rewrites list; agents apply these before retrieval so future similar queries hit the right code even when phrasing is off.

Persona selection (preference_key = "persona", COGNIREPO-402): Opt-in only — never enable a persona without the user explicitly asking. Valid values: "mentor" (deeper retrieval + full explanations + links to history), "pair" (default-equivalent, mood-aware phrasing), "caveman" (economy/telegraphic output, see COGNIREPO-403). "none" clears a previously-set persona (COGNIREPO-400-D01) — not a 4th persona. An unknown value is rejected, not stored — response includes {"recorded": false, "error": "..."}. Surfaced via get_user_profile()['active_persona'] / ['persona_behavior']. Precedence: explicit user request > persona > framing_hints/mood (see CLAUDE.md).

Claude: call this when:

  • User corrects your interpretation ("no, I meant X not Y")

  • User expresses a repeated preference ("always show code first")

  • User clarifies what a query actually means in this codebase

Do NOT call for one-off answers — only for durable preferences that should persist across sessions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contextNo
repo_pathNo
preference_keyYes
preference_valueYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.1

TDQS

A4.9/5.0
Behavior5/5

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

No annotations are present, so the description carries the full burden. It discloses persistence across sessions, where values are stored (explicit_preferences, query_rewrites, active_persona), the rejection of unknown persona values with response shape, and persona precedence.

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?

Organized with bold headings and short bullets; dense but every sentence adds operational value. The purpose is front-loaded before detailed call patterns.

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?

This is a high-complexity tool with no output schema and no annotations, yet the description covers all call patterns, storage surfaces, guardrails, and error behavior. The missing repo_path semantics is minor and does not prevent correct invocation.

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 0%, but the description compensates strongly by explaining preference_key semantics, valid persona values, and how preference_value/context map to query-rewrite corrections. The only gap is that repo_path is not described.

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 action ('Store') and resource ('explicit user preference or query-rewrite correction'), then breaks out the three key categories. It differentiates itself from sibling record/logging tools by defining what counts as a preference vs a one-off answer.

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

Usage Guidelines5/5

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

Explicit call conditions are provided: user corrections, repeated preferences, and query clarifications. It also gives an explicit exclusion: 'Do NOT call for one-off answers' and requires opt-in for persona selection.

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

Deploy Server

Other Tools