Skip to main content
Glama
Roxabi

roxabi-sense

Official
by Roxabi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

roxabi-sense

Workstation attention journal — light sensors, local store, agent surfaces.

Status: phases 1–3 live (collectors + store + CLI + daemon + MCP stdio) · NATS still stub
Not screenpipe. Not a web SaaS. Not inside roxabi-factory.
Agent SSOT: AGENTS.md · Claude shim: CLAUDE.md

Why

Screen capture + OCR is the wrong tool for “what was I doing?”.

You already have timestamped work in ~/.claude and ~/.grok. Meetings live in Claap. What is missing is a cheap focus spine: which app/window was active, which agent sessions were open, whether Slack/Discord was running — without pixels, keyloggers, or a 174 MB trial for 40 seconds of frames.

roxabi-sense is that spine. It publishes facts, not policy.

Related MCP server: Cortex

What it is / is not

Is

Is not

Local user-session daemon (systemd --user)

Factory hub module

CLI + optional MCP + optional NATS publisher

Screen OCR / continuous screenshots

Reads existing Claude/Grok session artifacts

Re-logs AI conversations

Focus / idle / process presence

Meeting recorder (→ Claap)

Edge sensor for Sentinelle later

Sentinelle decision brain (→ factory hub)

Architecture (target)

  collectors (facts only)
  ┌─────────────┐  ┌──────────────┐  ┌────────────────┐
  │ focus/idle  │  │ agent sessions│  │ process presence│
  │ (Wayland /  │  │ ~/.claude    │  │ slack/discord  │
  │  AT-SPI)    │  │ ~/.grok      │  │ (running?)     │
  └──────┬──────┘  └──────┬───────┘  └───────┬────────┘
         │                │                   │
         └────────────────┼───────────────────┘
                          ▼
                 local store (SQLite)
                 ~/.local/share/roxabi-sense/
                          │
          ┌───────────────┼────────────────┐
          ▼               ▼                ▼
        CLI             MCP              NATS (opt-in)
     day-slice      agent query    factory.event.host.*
     status         what_was_i…    activity | stale only

Boundary (ADR-091-aligned): sensors publish facts; roxabi-factory Sentinelle (hub module, not shipped yet) may consume host events and decide. This repo never opens Discord, never dispatches jobs, never applies ops policy.

Surface

Granularity

Depends on factory?

Local store + CLI

Fine timeline

No

MCP (stdio)

Query on demand

No

NATS plane ①

Coarse heartbeats (activity / stale)

Yes (bus up)

Details: docs/ARCHITECTURE.md · purpose: docs/PURPOSE.md

Stack decision

Local daemon + CLI + MCP — not a Silex web boilerplate.

Candidate

Verdict

silex-boilerplate / Next / multi-page web app

No — that shape is for client demos & product UI, not a user-session sensor

Full stack inside roxabi-factory

No — factory owns Sentinelle consumer; capture stays on the workstation

Python 3.13 + uv + systemd --user

Yes — matches Roxabi satellites (voiceCLI, xcli, cortex packages)

SQLite under ~/.local/share/roxabi-sense/

Yes — single-machine, Syncthing-friendly if paused

MCP stdio

Yes — Claude / Grok / Hermes

NATS publisher (optional extra)

Yes later — facts only, feature-flagged

Tiny 127.0.0.1 status page

Optional V2 — human glance only, not the product surface

Install matrix

Layer

What it does

How

Data plane

Always-on collectors → SQLite

sense install-service + systemctl --user enable --now roxabi-sense.service

Query plane

Read API for humans/agents

CLI: sense status / recap · MCP: sense mcp (stdio)

Agent DX

Host wires MCP

Grok/Claude host snippets or thin plugin plugins/roxabi-sense/ (.mcp.json → PATH sense mcp)

Data plane and query plane are separate: MCP does not start collectors. Empty/offline tools ⇒ fix the daemon, not the agent config.

Setup (PATH-stable)

Prefer a stable sense on PATH so agent configs never hardcode a worktree path.

# 1. clone (or pull) + install CLI + MCP deps into uv tool env
git clone git@github.com:Roxabi/roxabi-sense.git
cd roxabi-sense
uv tool install -e '.[mcp]'
# re-run after pull when the package changes:
#   uv tool install -e '.[mcp]' --force
# After PyPI release: uv tool install 'roxabi-sense[mcp]'

# 2. data plane — user systemd unit (not the same process as MCP)
sense install-service
systemctl --user enable --now roxabi-sense.service

# 3. smoke / DoD
sense doctor                  # FAIL if offline / no DB / MCP missing
sense status                  # last_tick should refresh while daemon is up
sense recap                   # day summary; Meetings fidelity=full|active_only
which sense                   # typically ~/.local/bin/sense

# 5. optional NATS (when factory Sentinelle is ready)
#    sense config set nats.enabled true

MCP host registration (Grok + Claude)

Prereq: steps 1–3 above — which sense resolves, sense doctor is green (daemon + DB + MCP SDK). MCP does not start collectors; empty tools ⇒ fix data plane first.

Happy path: host spawns sense mcp from PATH — never a worktree absolute path.

Grok

User-global TOML (~/.grok/config.toml):

[mcp_servers.roxabi-sense]
command = "sense"
args = ["mcp"]
enabled = true

Or CLI (same result; user scope is default):

grok mcp add roxabi-sense -- sense mcp
grok mcp doctor roxabi-sense   # config + spawn smoke

Restart the Grok session (or open a new one) so the server is re-spawned.

Claude Code

CLI (preferred one-liner):

# workstation-wide (recommended for a host sensor)
claude mcp add -s user roxabi-sense -- sense mcp

# or project-local (writes/approves .mcp.json in the repo)
claude mcp add -s project roxabi-sense -- sense mcp

Project .mcp.json (equivalent shape):

{
  "mcpServers": {
    "roxabi-sense": {
      "command": "sense",
      "args": ["mcp"]
    }
  }
}

Project-scoped servers may show as pending approval until accepted in Claude. User scope avoids per-repo approval for a machine-local sensor.

Asymmetry (intentional): Grok stores servers in TOML (~/.grok/config.toml or project .grok/config.toml); Claude uses CLI scopes / .mcp.json JSON. Both spawn the same stdio command: sense + mcp.

After registration

sense doctor          # still green (host config is not a substitute for data plane)
sense status          # last_tick moving while daemon is up

Then ask the agent for tools (sense_status, active_now, what_was_i_doing, …). If tools are missing: restart the host session; if tools return offline/empty: fix daemon/sense doctor, not MCP JSON.

Hardening (optional)

Pin absolute binary if PATH is unreliable in the agent environment:

# Grok example — replace with real path from `which sense`
[mcp_servers.roxabi-sense]
command = "/home/YOU/.local/bin/sense"
args = ["mcp"]
enabled = true

Dev-only fallback (not for agent configs)

# contributor smoke — do not paste worktree paths into host MCP configs
uv run --extra mcp --directory /path/to/durable/clone sense mcp

Editable uv tool install -e must point at a durable clone (e.g. ~/projects/roxabi-sense), not a feature worktree. If you delete that worktree, sense breaks with ModuleNotFoundError — reinstall:

cd ~/projects/roxabi-sense   # durable path
uv tool install -e '.[mcp]' --force
sense doctor

Privacy / trust

  • Default MCP redaction is coarse (no window titles / media tracks / full paths). Full detail only via operator config [mcp] detail = "full" — not tool-arg escalation (ADR-002).

  • Agent spawn trusts the sense binary on PATH. Prefer operator-owned uv tool install over a world-writable clone.

  • Only wire agents you trust with activity metadata.

Thin agent plugin (optional)

Optional DX package under plugins/roxabi-sense/ — wiring only:

Ships

Does not ship

.mcp.json → command: sense, args: [mcp]

Python runtime, collectors, AT-SPI

Skill: when/how to use sense_* tools

Second query layer / private SQL

Plugin README + missing-PATH fallback

systemd unit / daemon start

# Same happy path as host snippets — plugin just packages it:
#   command = "sense"  args = ["mcp"]
# Manual still wins until marketplace publish:
grok mcp add roxabi-sense -- sense mcp
claude mcp add -s user roxabi-sense -- sense mcp

Requires roxabi-sense[mcp] on PATH (package ≥ 0.0.1 with MCP extra) and sense doctor green. Full plugin notes: plugins/roxabi-sense/README.md.

Contributor / in-tree workflow (not for host MCP config):

cd roxabi-sense && uv sync --extra mcp
uv run sense status

No Podman required on the laptop for V1. M₂ may use the same user unit. M₁ host-sensor path (services snapshot only) is a later collector, not a Quadlet of this whole app.

Roadmap (coarse)

Phase

Deliverable

State

0 — scaffold

Public repo, purpose, architecture

done

1 — local spine

Agent-session collector + store + CLI status / day / recap

done

2 — focus + idle

Multi-backend focus probes + idle chain + process/mpris/tmux

done (P0+P1)

3 — MCP

stdio tools over SenseQuery (active_now, timeline, sessions, …)

done

4 — NATS opt-in

factory.event.host.{machine}.activity|stale for Sentinelle

open

5 — optional

Filtered browser history, local status HTTP

open

Focus probes (multi-Linux)

Focus is one collector (kind=focus) with swappable FocusProbe backends. Fact field source is the backend id (atspi | x11 | wlr | kde | noop).

Session

Candidate order (first healthy wins)

Wayland GNOME / Cosmic / unknown

atspi → x11 → noop

Wayland wlroots (Hyprland / Sway)

wlr → atspi → x11 → noop

Wayland KDE

atspi → kde (stub) → x11 → noop

Pure X11

x11 → atspi → noop

  • AT-SPI — long-lived agent (system Python + gi); best on GNOME/Cosmic when a11y works.

  • X11 — xprop / active window (XWayland fallback). Package: x11-utils.

  • wlr — hyprctl activewindow -j or swaymsg -t get_tree when compositor env is set.

  • kde — stub for now (probe() false until KWin D-Bus path lands).

  • Runtime demote — if AT-SPI dies, daemon switches to next healthy probe without blocking other collectors.

  • Meta focus: focus_backend, focus_status, session_type, desktop_family, last_focus_path.

  • Meta idle: idle_backend, idle_status, idle_chain_reason (wayland → logind → noop).

Agent sessions (Grok / Claude / optional Cursor)

Source

Default

Paths (read-only)

Grok

on (agent_sessions)

~/.grok/active_sessions.json

Claude

on (agent_sessions)

~/.claude/sessions/*.json

Cursor

off (cursor_sessions = true)

~/.config/Cursor/User/workspaceStorage/*/workspace.json

Cursor opt-in emits agent_sessions_snapshot with agent=cursor (workspace id + folder path + mtime only). Never opens chat DBs (state.vscdb), composer history, or rewrites agent dirs.

# ~/.config/roxabi-sense/config.toml
[collectors]
cursor_sessions = true
# cursor_root = "/home/you/.config/Cursor"   # optional override
# cursor_max_workspaces = 20
# cursor_max_age_days = 30

Agent status detail: AGENTS.md § Status.

Out of scope forever (for this repo): OCR, continuous screenshots, keylogging, clipboard dumps, scraping Slack/Discord desktop clients, meeting transcription, cloud upload of agent chat bodies.

Relation to the rest of Roxabi

Project

Relation

roxabi-factory

Future consumer (Sentinelle hub module). Not the home of collectors. ADR-091 factory-host-sensor role lives here as an edge process.

roxabi-cortex

Downstream memory/insight may ingest sense observations later. Sense stays capture + query, not the entity graph.

Claap

Meetings — do not duplicate

~/.claude / ~/.grok

Read-only sources for agent presence

License

AGPL-3.0-or-later (same family as roxabi-cortex).

Status

Phases 1–3 live (collectors, store, CLI, daemon, MCP stdio). Host registration: README § MCP host registration. NATS still open.

Available Tools

5 tools
active_nowB

Current presence, latest focus app, open agent sessions.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.1/5.0
Behavior2/5

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

There are no annotations, so the description carries the full burden for behavioral disclosure. It only lists content categories and does not mention return format, refresh semantics, permissions, side effects, or data source. All behavioral traits must be inferred from the tool name and content list.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded noun phrase with no filler words, making it very compact. However, the absence of a main verb makes it slightly less effective as a complete tool description.

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 zero-parameter tool with an output schema, listing the three content areas is minimally adequate. But without annotations or usage guidance, the description leaves behavioral and contextual details unstated and does not resolve overlap with sibling tools.

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?

The tool has zero parameters, so there are no parameter semantics to document. The baseline of 4 applies because no parameter information is needed.

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 identifies the three data areas returned: current presence, latest focus app, and open agent sessions. It lacks a main verb, making it a noun phrase rather than an explicit action statement, but the intent is readable. It does not explicitly differentiate from sibling tools that cover subsets of this data.

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 about when to use this tool versus alternatives. Sibling names like sense_status, what_was_i_doing, and agent_sessions suggest overlapping functionality, but the description offers no exclusion or preference cues.

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

agent_sessionsC

Claude/Grok sessions seen during a local calendar day.

ParametersJSON Schema
NameRequiredDescriptionDefault
dayNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.7/5.0
Behavior2/5

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

With no annotations, the description carries the full burden, but it only mentions the day scoping. It does not explain what 'sessions seen' means, how a local calendar day is interpreted (e.g., timezone), or what the response contains. This is minimal 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no unnecessary words, making it concise and easy to parse. It is slightly under-specified but not padded, so it earns a high score for structure.

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?

Although the tool is simple with one optional parameter, the description omits critical context such as the output structure (even though an output schema exists, the description should clarify what sessions are listed), the meaning of 'seen', and how 'local calendar day' is determined. This is incomplete for an agent deciding to invoke it.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for the undocumented 'day' parameter. It mentions 'local calendar day' but does not specify the day's format, accepted values, or the meaning of null default, leaving the parameter ambiguous.

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 states that the tool shows Claude/Grok sessions seen during a local calendar day, which conveys the resource (sessions) and scope (a day). However, the verb 'seen' is vague and does not explicitly say 'list' or 'retrieve', and it does not distinguish this from sibling tools like day_recap.

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 given about when to use this tool versus alternatives like active_now or what_was_i_doing. It neither mentions appropriate conditions nor provides exclusions, so an agent has no basis for choosing it over siblings.

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

day_recapC

Compiled day recap (apps, away, meetings, agents) as JSON.

ParametersJSON Schema
NameRequiredDescriptionDefault
dayNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.6/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 only states the output format (JSON) and content categories, but does not disclose behavior regarding the optional 'day' parameter, default behavior, or what the recap actually covers. This is insufficient for an agent to understand tool behavior beyond the basic output.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words, clearly front-loaded with the core purpose. It lacks structural breakdown of the output fields, but that is not strictly required for conciseness. It earns a strong score for brevity.

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 tool is relatively simple with one optional parameter and an output schema, but the description lacks essential context: what 'day' expects, what happens if omitted, and how this differs from related tools. Given the output schema exists, not explaining return values is acceptable, but the usage context is missing.

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

Parameters1/5

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

The schema has zero parameter descriptions (0% coverage), and the description does not explain the 'day' parameter's format, allowed values, or default behavior. With only one parameter and no compensation in the description, an agent has no idea what to pass.

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 indicates the tool produces a compiled day recap with specific categories (apps, away, meetings, agents) and notes the JSON output. It distinguishes from sibling tools that focus on current status or specific sessions, though it lacks an explicit verb like 'get' or 'retrieve'.

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 about when to use this tool instead of alternatives like active_now or what_was_i_doing. The description does not mention typical use cases, prerequisites, or exclusions.

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

sense_statusC

Daemon health, presence, last collect meta.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations, the description carries the full burden of disclosing behavioral traits. It does not explicitly state that this is a read-only status check, nor does it mention side effects, permissions, or rate limits. The phrase 'Daemon health, presence, last collect meta' implies informational use but does not clearly disclose behavior beyond that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely terse, at five words, which makes it efficient but under-specified. It lacks a subject-verb structure and reads as a fragment rather than a clear sentence. While it is front-loaded, its brevity sacrifices clarity, making it only partially effective.

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 that the tool has no parameters and an output schema exists, the description does not need to detail return values. However, the description is still cryptic, leaving terms like 'presence' and 'last collect meta' undefined. It provides minimal context for an agent to understand the tool's role, though it is adequate for a very simple status endpoint.

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?

The tool has zero parameters, so there are no parameter semantics to explain. The schema coverage is vacuously 100%, and the description does not need to elaborate on input. The baseline score of 4 is appropriate because no parameters exist and the description doesn't introduce confusion.

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

Purpose3/5

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

The description is a noun phrase listing 'Daemon health, presence, last collect meta,' which hints at the tool's purpose but lacks an explicit verb such as 'get' or 'return.' It does not clearly state what the tool does with these items, making the purpose somewhat vague. It also does not differentiate itself from sibling tools beyond the implied system status subject.

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 provides no guidance on when to use this tool versus alternatives. It neither states conditions for use nor mentions any exclusions or sibling tools. The context signals show sibling tools like 'active_now' and 'agent_sessions,' but the description does not help the agent decide between them.

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

what_was_i_doingB

Timeline for a local calendar day (YYYY-MM-DD); default today.

Returns summarized events (coarse by default). limit caps event count.

ParametersJSON Schema
NameRequiredDescriptionDefault
dayNo
limitNo

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It discloses that events are summarized and coarse by default, and that limit caps event count. However, it does not explain what 'coarse' means, timezone handling, or whether it includes all-day events. It adds some behavioral context but is not comprehensive.

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, front-loaded with the core purpose and defaults. Every sentence earns its place without redundancy or filler. It is appropriately concise for the tool's simplicity.

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 and has an output schema (not shown), so the description does not need to detail return values. However, it lacks guidance on semantics of 'coarse' events, interactions with limit, and fit within the sibling toolset. The description is adequate for basic use but leaves ambiguity that could lead to incorrect 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%, so the description must compensate. It does: it specifies day uses YYYY-MM-DD format and defaults to today, and limit caps event count. This adds clear meaning to both parameters beyond the bare schema, though it omits details like limit bounds or behavior when omitted.

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 states the tool provides a timeline for a local calendar day, returning summarized events. The verb is implicit but the resource and action are clear: it retrieves what you were doing on a given day. It does not explicitly distinguish from sibling tools like day_recap, so it is clear but lacks differentiation.

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 gives no guidance on when to use this tool versus alternatives such as day_recap or active_now. It mentions default behavior (today, coarse) but does not specify use cases, exclusions, or preferability. This is a clear gap for a tool with several siblings.

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.

  1. 5 tool updatesv0.0.1
    • First observedactive_now
    • First observedagent_sessions
    • First observedday_recap
    • First observedsense_status
    • First observedwhat_was_i_doing
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.2/5.0

Scored across 5 tools

Disambiguation4/5

Most tools have distinct purposes: daemon health, current presence, daily timeline, agent sessions, and day recap. However, what_was_i_doing and day_recap both cover a day's activities, and agent_sessions is a subset of the timeline, creating minor overlap that descriptions help resolve.

Naming Consistency3/5

Names are readable and mostly snake_case, but patterns vary: sense_status and agent_sessions are noun_noun, active_now is adjective_noun, what_was_i_doing is a sentence fragment, and day_recap is noun_noun. No consistent verb_noun or clear pattern, though not chaotic.

Tool Count5/5

Five tools is well-scoped for a personal sense daemon covering health, presence, timeline, sessions, and recap. Each tool earns its place without redundancy or bloat.

Completeness4/5

The surface covers core lifecycle needs: status, current state, historical timeline, specific session data, and a compiled recap. Missing minor capabilities like searching or filtering events, but agents can work around these gaps for typical tasks.

Maintenance

ActivityActive
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • Cortex

    turfptax
    A
    license
    Not graded
    quality
    F
    maintenance
    Provides persistent memory to AI agents through a wearable device, storing notes, sessions, and activities in a local SQLite database accessible via MCP.
    MIT

  • joa

    neethanwu
    A
    license
    Not graded
    quality
    C
    maintenance
    Persistent activity journal for AI agents - enables logging and querying decisions, changes, errors, and observations across sessions.
    13
    1
    MIT

  • nuzo-memory

    fabionfsc
    A
    license
    Not graded
    quality
    F
    maintenance
    Local-first, auditable memory for AI agents. Provides durable context for MCP hosts with SQLite storage, CLI, and MCP tools for memory management.
    2
    Apache 2.0