A
licenseNot graded
qualityD
maintenanceAn MCP server that stores atomic facts extracted from text, links them to entities and relationships, and synthesizes higher-order observations (patterns, preferences, insights) via a reflect loop.
21
3
MIT
user-db
by NG-Bullseye
Exposes virtual sensor values (e.g., user stress, room intensity) to Home Assistant via command_line sensors for real-time smart-home automation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@user-dbwhat's my current stress level?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
user-db
Central user-state database as an MCP server: durable profile facts plus live virtual sensors (user stress level, room intensity) with configurable smoothing — readable in real time by any agent or smart-home service.
Data separation (important)
This repository contains software only. All personal data lives outside
the repo, in the directory given by USER_DB_DIR (default ~/.config/user-db/):
File | Content | Written by |
| durable user facts (name, speech id, birthday, profession, expertise, traits, ...) | you / agents via |
| sensor + curve configuration (reactiveness tuning) | you |
| live sensor state | this software |
Nothing in this repo ever contains user data; examples/ holds neutral
templates. Copy them to USER_DB_DIR to get started:
mkdir -p ~/.config/user-db
cp examples/*.json ~/.config/user-db/Related MCP server: Clark MCP Server
Install & run
python3 -m venv .venv && .venv/bin/pip install mcp
claude mcp add --scope user user-db -- $PWD/.venv/bin/python $PWD/server.pyCLI (same core, for shell loops and Home Assistant command_line sensors):
bin/userdb profile
bin/userdb sensor report stress 70
bin/userdb sensor read stress
bin/userdb stateMCP tools
profile_get/profile_set(field, value)— the user's durable state.sensor_read(name)/sensor_report(name, value)— virtual sensors.state_get— all sensors + the curve combining both axes.
Virtual sensors & reactiveness
A sensor value is not a plain variable. Producers report raw observations (0–100); the stored value follows them via time-aware exponential smoothing:
alpha = 1 - exp(-dt / tau_seconds)
value += alpha * (raw - value)tau_seconds per sensor in config.json is the reactiveness: small tau =
reactive, large tau = inert. This keeps the sensor from jumping and lets you
fine-tune it for smart-home automations. The first report initialises the
value directly.
Default sensors: stress (the user's stress level, reported by a
watchdog/perception agent) and room_intensity (the room's current scene
intensity, reported by a scene-analysis agent — see
docs/neuronal-interceptor.md).
The two axes & the curve
The system has two orthogonal axes: user stress and room intensity.
A freely definable piecewise-linear curve in config.json maps stress to a
target room intensity:
"curve": {"x": "stress", "y": "room_intensity",
"points": [[0, 85], [40, 60], [70, 35], [100, 15]]}state_get evaluates it and returns target and delta (actual − target) —
the basis for smart-home decisions ("the user is stressed but the room is
loud → calm it down").
Home Assistant
Expose the smoothed value as a command_line sensor, or bridge it through an
existing MCP that already abstracts Home Assistant:
sensor:
- platform: command_line
name: user_stress
command: "/path/to/user-db/bin/userdb sensor read stress | jq .value"
scan_interval: 60License
MIT
Available Tools
5 toolsprofile_getA
Read the full user profile (name, speech_id, birthday, profession, expertise, durable traits, ...). Describes the user's durable state.
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 provided, so description carries full burden. The term 'Read' implies safe, read-only behavior, and 'describes durable state' adds context. However, it does not mention authentication requirements, rate limits, or any potential constraints.
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?
Extremely concise: two short sentences with no redundant information. Every part adds value.
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 no parameters, no output schema, and no annotations, the description sufficiently explains what the tool returns and its purpose (user's durable state). Minor improvement could mention format or scope (e.g., current user).
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 in schema, so description naturally doesn't add parameter info. Baseline for 0 parameters is 4, and the description does not detract from this.
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 it reads the full user profile, listing example fields like name, speech_id, birthday, etc. It distinguishes from siblings such as profile_set (write operation) and sensor_read/sensor_report (sensor-related).
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?
Implicitly specifies when to use: to retrieve user profile data. Does not explicitly state when not to use, but the simplicity and lack of parameters make it obvious. Sibling tools provide clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
profile_setA
Set one profile field. value is parsed as JSON when possible
(lists/numbers/null), otherwise stored as plain string. value="null"
deletes the field. Returns the updated profile.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | ||
| value | Yes |
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses JSON parsing, plain string fallback, deletion behavior for 'null', and return of updated profile.
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?
Two concise sentences, front-loaded with purpose, no redundancy.
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?
Covers purpose, parameter behavior, and return value ('Returns the updated profile'); adequate for a simple set tool with no output schema.
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 description adds significant meaning: explains value parsing and deletion semantics beyond schema's simple string type.
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 clearly states 'Set one profile field' with specific verb and resource, and distinguishes from sibling tools like profile_get, sensor_read, 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?
No explicit when-to-use or when-not-to-use guidance; usage is implied but not contrasted with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sensor_readB
Read a virtual sensor (e.g. "stress", "room_intensity"): smoothed value, last raw observation, last update time.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | stress |
TDQS
B3.4/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 the burden. It describes the return data (smoothed, raw, time) but does not explicitly state the operation is read-only or disclose any side effects.
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 concise sentence that immediately conveys the tool's purpose and return values, with no redundant content.
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 tool with one parameter and no output schema, the description is largely complete. It defines the operation and return fields. Lacks explicit mention of default behavior or read-only nature.
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?
With 0% schema description coverage, the description compensates by providing example sensor names ('stress', 'room_intensity'), but does not explain the parameter meaning or allowed values beyond examples.
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 tool reads a virtual sensor and lists the return values (smoothed value, raw observation, update time), with examples. It does not explicitly differentiate from sibling sensor_report, but the verb 'read' implies retrieval.
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 sensor_report or state_get. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
sensor_reportA
Report a raw observation (0-100) for a virtual sensor. The stored value follows it smoothly (time-aware exponential smoothing; the tau_seconds reactiveness per sensor is set in config.json). Returns the new smoothed state. Use name="stress" for the user's stress level and name="room_intensity" for the room's current intensity.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| value | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behavioral traits: raw input is smoothed via time-aware exponential smoothing, the stored state updates, and the smoothed state is returned. It does not cover permissions or errors, but the scope is adequate for a straightforward sensor reporting tool.
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 concise and well-structured: it starts with the action, explains the smoothing behavior, and ends with usage examples. Every sentence adds value without redundancy.
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 the tool's simplicity and lack of output schema, the description covers the purpose, parameter constraints, behavioral details, and return value. It does not mention error conditions or prerequisites, but it is sufficiently complete for an AI agent to use correctly.
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?
With 0% schema description coverage, the description fully compensates by explaining that 'name' must be 'stress' or 'room_intensity' and 'value' is a raw observation between 0-100. This adds crucial semantics beyond the bare 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's purpose: reporting a raw observation for a virtual sensor. It specifies the value range (0-100), mentions exponential smoothing, and gives concrete name examples ('stress', 'room_intensity'), distinguishing it from sibling tools like sensor_read.
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 guidance on when to use the tool (to report observations) and which names to use. It does not explicitly state when not to use it or how it differs from siblings, but the context is strong enough for an AI agent to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
state_getA
Read the full live state: all virtual sensors plus the curve that combines both axes (target room intensity for the current stress level, and the delta between actual and target).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'Read' clearly indicates idempotent, non-destructive behavior. With no annotations, this is sufficient. Could be enhanced by explicitly stating 'no side effects' or 'safe to call repeatedly'.
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 with no wasted words. Verb 'Read' is front-loaded, and the description efficiently specifies what is included.
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?
Despite no output schema, the description fully explains what is returned (virtual sensors plus curve with axis details). No additional context needed given tool simplicity.
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 exist, so the description does not need to add parameter info. Baseline 4 for zero-parameter tools 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?
Description clearly states 'Read the full live state' with a verb and specific resource (virtual sensors plus curve). Distinguishes itself from sibling tools like sensor_read or profile_get by focusing on combined state.
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 (e.g., sensor_read for individual sensors). The description implies it's for holistic state, but lacks explicit when-not-to-use or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
5 tool updates
v0.1.0- First observed
profile_get - First observed
profile_set - First observed
sensor_read - First observed
sensor_report - First observed
state_get
TDQS
A4.1/5.0
Disambiguation5/5
Each tool targets a unique function: profile (get/set), sensor (read/report), and composite state. No overlap or ambiguity.
Naming Consistency5/5
All tools follow the verb_noun snake_case pattern consistently (e.g., profile_get, sensor_read, state_get). Naming is predictable.
Tool Count5/5
With 5 tools, the server covers profile management, sensor data operations, and a combined state view—perfectly scoped for a user-db server.
Completeness4/5
Covers core CRUD for profile (get/set with delete via null) and sensor read/report. Missing explicit profile delete or sensor listing, but set handles deletion and state_get lists sensors.
Maintenance
ActivitySlowing
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
Governed personal world model and memory for your AI agent. Pair once, connect over MCP.
Private-by-default, local-first memory/context/task orchestrator for MCP apps and agents.
Agent-native MCP server over 49M+ US public and government records, privacy-first, always current.
Person-owned AI memory that learns, not just stores — portable context for any MCP client.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides a memory layer for personal agents, enabling MCP-compatible agents to store and query profile, factual, episodic, and procedural memory.MIT
- FlicenseNot gradedqualityDmaintenanceA local MCP server that maintains and serves personal identity context to LLMs.-
- AlicenseNot gradedqualityAmaintenanceLocal-first stdio MCP server for agent relationship-continuity state: PAD mood, affective pulse, trust, decay, and boundary signals kept beside factual memory.24MIT
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/NG-Bullseye/user-db'
If you have feedback or need assistance with the MCP directory API, please join our Discord server