Skip to main content
Glama

Stickies (Claude Code plugin)

npm MCP Registry License: MIT Node

Persistent sticky notes for Claude Code. You pin a note — a decision, a blocker, a todo — and it survives session resets, /clear, and closing the terminal. Next time you open Claude in that project, the notes that still matter are handed back to it automatically.

Stickies is not a memory system, and it doesn't try to be one. It won't watch your session and decide what to remember. It's the opposite: a handful of notes you (or Claude, on request) write down on purpose, that expire on their own, and that you can read, prune, and trust. No vectors, no LLM summarization, no cloud. If you want an AI that auto-remembers everything, use Claude Code's built-in memory — it's on by default. Stickies is for when you want the twenty notes that actually matter, and you want them to expire.


Quick start (60 seconds)

You need Node ≥ 22.5 (node -v to check — it's for the built-in SQLite).

claude plugin marketplace add dumbspacecookie/stickies
claude plugin install stickies@stickies --scope user

Restart Claude Code. That's it — install once, it works in every project. Now try it:

  • Ask Claude to remember something: "pin a P1 todo: fix the auth leak before release." Claude writes it down; it'll be waiting for you next session.

  • See your notes: type /stickies in Claude Code. Prefer a shell? npm i -g stickies-mcp gives you a stickies command — then stickies list.

  • Open the board in a browser: /stickies dashboard, then stickies dashboard --link for an authorized URL (the board serves your notes, so it only answers a browser you've let in).

Nothing leaves your machine. Everything is a local SQLite file on your disk until you turn on optional git sync.


Related MCP server: Vibe Board VE

Where it works

Notes belong to the project, not the app you're in — one local database, scoped by project. What changes between surfaces is how much happens automatically.

Surface

What you get

How

Terminal (Claude Code CLI)

✅ the full loop — auto-capture, session-start digest, /stickies, statusline, dashboard

install the plugin

Claude Desktop (chat app)

✅ read / write via MCP tools (no hooks; pass the project path)

add the MCP server to claude_desktop_config.json

iPhone / web (Remote Control)

✅ full loop — the phone drives a session running on your machine

run claude remote-control on your machine

iPhone / web (cloud sandbox)

✅ full loop via repo-mode — notes committed into the repo

stickies init-repo (see Repo-mode)

Any MCP client

✅ read / write

it's on the MCP Registry as io.github.dumbspacecookie/stickies

Anywhere, read-only

✅ a glance at your board

Discord digest / board card


Two things here you won't find elsewhere

  • Zero-turn capture. Claude parks a note by writing one line in a reply it was already writing!!sticky todo P1 :: fix the auth leak — and a Stop hook persists it. No extra tool call, no extra turn, no tokens spent on a round-trip. (See Auto-capture.)

  • Importance-graded injection. The session-start digest degrades by importance, not by position: P1 in full, P2 truncated, P3 a bare count. It never just chops the list at N lines.


Flow Board

If your project plans work in a .planning/ROADMAP.md (the GSD planning convention), Stickies also gives you a live Kanban board derived straight from that roadmap — To-Do / Doing / Done — with your stickies cross-linked onto the phases they're about. It's a projection of your plan, derived on the fly, so it can never drift out of sync with it.

Four places to see the same board, pick whichever fits where you are:

Where

Command

Good for

On GitHub / your phone

stickies board → commit BOARD.md

glancing at progress from a phone browser — BOARD.md renders natively on github.com, no server, no app

In a browser (local)

stickies dashboard → open /board

an interactive Kanban; /graph shows the plan's dependency DAG

In Discord

stickies board --discord

a push-glanceable card — progress, column counts, per-phase status

In your statusline

(see Statusline)

a tiny always-on 📋 ▶2 ☐1 ✓2 (doing / to-do / done)

stickies board                     # write BOARD.md in the project root (commit it → view on GitHub)
stickies board --out docs/BOARD.md # write it somewhere else
stickies board --discord           # post the board to your Discord webhook instead

Each phase shows its progress (3/4), its wave, whether it shipped (✓ shipped 4/4) and whether it's blocked (). In a cloud/mobile session with no .planning/, a committed .flow/ snapshot keeps the board self-sufficient — same repo-mode idea as the notes.


Everyday commands

In Claude Code (the /stickies slash command):

Command

Does

/stickies

list this project's active notes (+ globals)

/stickies all

list every project's notes

/stickies add <text>

add a note by hand

/stickies dismiss <id>

clear a note (a todo is "done" when dismissed)

/stickies dashboard

open the local web board

/stickies sync

sync through your git repo (if configured)

In any shell (the CLI — same engine). Install it with npm i -g stickies-mcp to get the stickies command on your PATH, then:

stickies list                          # active notes for this dir + globals
stickies list --all                    # every project + globals
stickies add "ship the release" -c todo -i P1     # add a P1 todo to this project
stickies add "pay invoice" -c todo --due 2d       # a deadline (30m/2h/1d/1w/tomorrow/YYYY-MM-DD)
stickies add "call the bank" -c todo -p global    # a global todo — shows up everywhere
stickies dismiss <id> -r "done"        # clear it
stickies dashboard --open              # local web board, open the browser
stickies board                         # write a GitHub-viewable BOARD.md
stickies status                        # the one-line statusline summary
stickies sync                          # pull → merge → commit (push needs STICKIES_SYNC_PUSH=1)
stickies notify                        # push the open list to Discord
stickies init-repo                     # make notes work in cloud/mobile (repo-mode)

Auto-capture

The lowest-friction way in: Claude captures a durable fact by writing one line in its reply, and a Stop hook persists it — no tool call, no extra turn.

!!sticky <category> [P1|P2|P3] [global] [#tag ...] :: <content>
!!sticky decision P1 #storage :: storage is node:sqlite, no native deps
!!sticky todo P1 global :: cut the npm release

category is required; importance defaults to P2; notes are deduped. global and #tags are optional and may appear in any order. Without global, a note is scoped to the current project; with it, the note surfaces in every project.

The hook scans the whole completed turn, so a directive written before Claude runs more tools still gets saved. Directives inside subagent replies are ignored. Secrets are scrubbed on write.


Statusline

Point your Claude Code statusline at Stickies to get an always-on summary. It's opt-in — add this to your settings.json:

{ "statusLine": { "type": "command", "command": "stickies status" } }

(that uses the stickies command from npm i -g stickies-mcp)

By default it's compact — a count plus an urgency flag, e.g. 🟨 2!·19 (2 urgent of 19). It deliberately does not print note text (so nothing sensitive lands in your prompt); set STICKIES_STATUSLINE_VERBOSE=1 if you want the top note's text too.

Light / dark. A statusline can't repaint your terminal's background — it can only colour its own text — so the theme's job is to stay legible on whatever background you already have. The dark palette (default) uses the terminal's own bright colours; the light palette swaps in darker truecolour values that survive a white background (tuned to clear WCAG AA text contrast). Pick it with STICKIES_THEME=light (or dark) in your environment, or per-invocation with stickies status --light / --theme dark. On macOS/Linux terminals that publish $COLORFGBG it also autodetects; Windows Terminal / PowerShell don't set that variable, so on Windows set STICKIES_THEME explicitly if you run a light terminal. The dashboard (/, /board, /graph) is a real web page, so it gets a full ☾/☀ toggle that flips the whole background — that's a page it owns, unlike the statusline.

Clickable link. In a terminal that supports OSC-8 hyperlinks (Windows Terminal, iTerm2, WezTerm, Kitty, Ghostty) the segment becomes a Ctrl+click link that opens the dashboard. Two things it needs:

  • A dashboard must actually be runningstickies dashboard --detach. The segment is a link only while one is; with none running you still get the counts, just not underlined and not clickable. That is deliberate: a link to a closed port looks alive, fails only when you click it, and blames your browser rather than us. Autostart is off unless you ask for it, so no link is the default state on a fresh install. If the segment is not clickable and you expected it to be, stickies doctor says which of these two it is.

  • On Windows Terminal, Claude Code doesn't auto-detect hyperlink support, so set FORCE_HYPERLINK=1 in your environment before launching Claude Code (e.g. setx FORCE_HYPERLINK 1, then restart). Without it the segment renders but isn't clickable.

The link auto-skips under tmux (which mangles OSC-8), disables with --no-link, and its port follows STICKIES_DASHBOARD_PORT.


Dashboard

stickies dashboard                 # http://127.0.0.1:7317/
stickies dashboard --open          # and open the browser
stickies dashboard --detach        # run in the background
stickies dashboard --link          # print an authorized URL for a browser
stickies dashboard --stop          # stop the running one

Loopback only (never leaves 127.0.0.1). Routes: / the notes board, /board the Flow Board Kanban, /graph the plan dependency DAG. One dashboard covers every project you take notes in — the header switcher moves between them, so you don't run one per folder.

It only starts when you ask. Installing Stickies does not put a server on your machine. If you'd rather each Claude session bring one up automatically, set STICKIES_DASHBOARD_AUTOSTART=1 (skipped in CI and remote sessions regardless).

"Not authorized"? That's expected, not a bug. The dashboard serves your notes and planning documents, so it answers only a browser you've authorized:

stickies dashboard --link          # → paste into your browser

…or Ctrl+click the Stickies segment in your statusline, which carries one. Opening the link sets a cookie; that's what lasts. Links themselves expire after a few minutes, so an old one from your scrollback will be refused — get a fresh one. Prefer it open? STICKIES_DASHBOARD_AUTH=0.

Editing the plan from the board is off by default. With STICKIES_BOARD_WRITEBACK=1, dragging a card rewrites that phase's **Status:** line in .planning/ROADMAP.md, keeping a pre-edit copy in .flow/roadmap-backups/. A move that contradicts the phase's plan checkboxes is refused rather than written.

Something not behaving? stickies doctor reports the whole setup in one shot — what's running, on which port, whether the installed plugin copy is stale — with your home directory abbreviated to ~ so the output is safe to paste.


Provenance

Every note records where it was written — 💻 terminal, 🖥️ desktop, or 📱 mobile — so on the dashboard you can tell the note you jotted from your phone from the one Claude captured at your desk. It's a best-effort stamp each entry point knows about itself; no configuration needed.


Sync (git-backed, opt-in)

Sync through a git repo you own — no third-party service, no new account. This is the only feature that ever touches the network, and only once you point it at a remote.

export STICKIES_SYNC_REPO=/path/to/your/stickies-data   # a git clone you control
stickies sync           # pull → merge (last-writer-wins) → export → commit (push: STICKIES_SYNC_PUSH=1)

# or offline, through any file channel:
stickies export -f notes.json
stickies import -f notes.json

Each note carries a machine-independent key derived from the project's git remote (SSH and HTTPS collapse to the same key), so a project's notes follow you between machines even when the checkout lives at a different path on each. Merge is whole-record last-writer-wins by updated_at — conflict-free and order-independent.

Auto-sync (also opt-in): set STICKIES_AUTO_SYNC=1 alongside STICKIES_SYNC_REPO and Stickies pulls on session start and commits when a turn captures a note. Unset, nothing syncs on its own.

Pushing is a third opt-in. Capturing a note commits to your sync repo and stops there — STICKIES_SYNC_PUSH=1 is what makes it git push as well. Without it your notes are versioned locally and never leave the machine, so a second machine will never see them. The push runs bare (no remote, no refspec) so your own git config decides where it goes; deriving that ourselves went wrong three separate ways, once writing a stray branch onto a shared main.


Repo-mode (cloud / mobile)

The plugin lives in ~/.claude, so it doesn't exist in a cloud session (the iPhone app / claude.ai/code run in an ephemeral VM that only sees the repo they cloned). Repo-mode makes Stickies work there — no plugin, nothing to install:

stickies init-repo         # run inside the repo you want notes in

That commits a self-contained, zero-dependency engine and wires it up:

  • .stickies/notes.json — the store, plus a human-readable .stickies/NOTES.md mirror

  • .claude/settings.json — a SessionStart hook (the digest) and a Stop hook (!!sticky capture)

  • CLAUDE.md — teaches Claude the !!sticky convention

  • .github/workflows/stickies-sync.yml — converges notes from every session branch into main

Cloud sessions write to their own branch; the bundled Action merges each note into main (union + dismiss-wins + dedupe) — one converged board per repo, hands-off. Same !!sticky grammar and same redaction as the local plugin.

Two things worth knowing before you run it: your notes live in that repo, so they are as public as it is; and if a step can't be done safely — an unparseable .claude/settings.json, most often an unresolved merge conflict — that file is left alone and the command warns and exits non-zero rather than replacing it.


The sticky model

Fields: id, content (≤ 500 chars), category, importance (P1/P2/P3), project_path (absolute, or null for global), tags[], origin, timestamps, expires_at, source (auto/manual), status (active/stale/dismissed).

Default TTLs: decision 30d · blocker 7d · preference 90d · context 14d · todo never expires (a task is done when you dismiss it, not when a timer runs out). That last one is what makes todo + global a real cross-project task list — an unfinished task can't silently vanish.

Storage: one SQLite file for all projects, scoped per-project — $STICKIES_DB if set, else ~/.stickies/stickies.db. It uses Node's built-in SQLite (node:sqlite, hence Node ≥ 22.5), so the plugin has zero compiled dependencies and survives Claude Code's plugin-cache copy on any machine.

Session-start digest: P1 in full, P2 to ~100 chars, P3 a count. It's handed to Claude through the SessionStart hook's additionalContext — it reaches the model without writing to any file.


Claude Desktop (MCP only)

Claude Desktop supports the MCP tools (stickies_write / stickies_read / stickies_dismiss) but not hooks or the slash command, so there's no auto-capture or digest there — add it and pass the project path explicitly. In claude_desktop_config.json (%APPDATA%\Claude\ on Windows, ~/Library/Application Support/Claude/ on macOS):

{
  "mcpServers": {
    "stickies": {
      "command": "node",
      "args": ["--disable-warning=ExperimentalWarning", "/abs/path/to/stickies/src/server.js"]
    }
  }
}

Both clients read the same ~/.stickies/stickies.db, so a note written in one shows up in the other with no sync step.


Components (reference)

Component

File

Purpose

MCP server

src/server.js

tools stickies_write / stickies_read / stickies_dismiss

SessionStart hook

src/session-start.js

injects the digest via additionalContext (touches no file)

Stop hook (auto-capture)

src/auto-capture.js, src/directives.js

persists !!sticky … directives, deduped

Local dashboard

src/dashboard.js, src/dashboard-page.js

loopback web UI: notes, /board, /graph

Flow Board

src/flow/

derive the Kanban from .planning/ROADMAP.md; BOARD.md export; .flow/ snapshot

Slash command

commands/stickies.md

/stickies …

CLI

src/cli.js

backs the slash command; usable directly

Store / DB

src/store.js, src/db.js

CRUD + schema + TTL + dedup + provenance

Sync

src/sync.js, src/git-sync.js

export/import + git pull→merge→commit (push is opt-in)

Redaction

src/redact.js

scrubs secrets from content on write

Repo-mode

src/repo-mode/

committed store + hooks + reconcile Action for cloud/mobile


Install & develop

# use it:
claude plugin marketplace add dumbspacecookie/stickies
claude plugin install stickies@stickies --scope user     # restart Claude Code after

# work on it:
git clone https://github.com/dumbspacecookie/stickies
cd stickies
npm test        # 27 suites, 558 assertions, no network

Install once at user scope and it's in every project; per-project scoping is by project_path on each note, not a per-project install.


How Stickies compares

Persistent-notes-for-Claude-Code is a crowded space. Honestly:

  • Claude Code's built-in memory — on by default, the model decides what to save, no expiry, no importance tiers, no cross-project globals, per-repo only. Stickies is the deterministic, human-authored, expiring alternative for people who turned that off.

  • Knowledge-graph / vector memory servers (mem0, OpenMemory, server-memory, basic-memory) — fuzzy retrieval over everything you've said. Different job. Stickies stores a small typed set, not an embedding index.

  • Hook-based memory plugins — several exist, some excellent. Stickies' narrow bets are the ones above: zero-turn !!sticky capture, importance-graded injection, a global tier that surfaces across projects, and a Flow Board derived from your plan.

If you want auto-recall of your whole history, use one of those. Stickies is for a short, trustworthy, self-pruning list — and a board you can glance at from your phone.


MIT · built by dumbspacecookie

Available Tools

3 tools
stickies_dismissDismiss a stickyA

Soft-delete a sticky by id (marks it dismissed; it is no longer read back).

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe sticky id to dismiss.
reasonNoOptional reason for dismissal.

TDQS

A4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden and does well by explicitly disclosing that this is a soft-delete (not a hard delete), that it marks the item as dismissed, and that dismissed stickies are no longer read back. It could add idempotency or permission details, but the key behavioral trait is clearly communicated.

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 primary action, and contains no unnecessary words. It efficiently conveys both the action and its consequence.

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 two-parameter tool with no output schema, the description is largely complete: it states the action and the outcome. It does not discuss reversal or error behavior, but given the low complexity and schema coverage, this is a minor gap.

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 input schema already provides full descriptions for both parameters (id and optional reason), and schema coverage is 100%. The description adds no additional meaning beyond 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 uses a specific verb ('soft-delete') with a specific resource ('a sticky by id') and explains the effect ('marks it dismissed; it is no longer read back'). This clearly distinguishes it from sibling tools like stickies_read and stickies_write.

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 when to use the tool (when a sticky should no longer be read back) but does not explicitly contrast it with alternatives or state when not to use it. There is no mention of using stickies_write for other mutations, so guidance is only implied.

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

stickies_readRead stickiesA

Retrieve active stickies relevant to the current session, ordered by importance.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax stickies to return.
project_pathNoAbsolute project root to scope to. Omit to read across all projects.
include_globalNoAlso include global (no project) stickies.
min_importanceNoLowest importance to include (P1 = only critical).P3

TDQS

A4/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 behavioral disclosure burden. It does reveal that only 'active' stickies are returned and that results are ordered by importance, which is useful filtering behavior. However, it does not explicitly state that the operation is read-only (beyond the verb 'Retrieve'), nor does it explain what 'active' means or how 'relevance' is determined.

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 front-loads the core purpose. Every word earns its place, with no redundant phrasing or unnecessary detail.

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 read tool with well-documented schema and no output schema, the description is fairly complete. It covers the essential purpose and key behavioral traits. However, it could be slightly more complete by clarifying what 'active' means or what the response looks like, but the core functionality is adequately conveyed.

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%, so all parameters (limit, project_path, include_global, min_importance) are already documented in the schema. The description adds a small semantic link by mentioning 'ordered by importance,' which relates to min_importance, but it does not significantly enhance understanding beyond the 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 action ('Retrieve'), the resource ('active stickies'), the scope ('current session'), and the ordering ('by importance'). This distinguishes it from sibling tools like stickies_write and stickies_dismiss, making the purpose unambiguous.

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: to retrieve active stickies relevant to the current session, with a specific ordering. It implies use for reading existing stickies rather than creating or dismissing them, but it does not explicitly mention alternatives or exclusions.

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

stickies_writeWrite a stickyA

Create a persistent sticky note. Call this when a durable fact emerges (a decision, blocker, preference, context, or todo) that future sessions should retain.

ParametersJSON Schema
NameRequiredDescriptionDefault
tagsNoOptional string tags (max 20, each ≤40 chars).
contentYesFreeform note text, max 500 chars.
categoryYesdecision | blocker | preference | context | todo (sets the TTL).
importanceNoP1 critical, P2 normal, P3 minor.P2
project_pathNoAbsolute project root this note belongs to. Omit/null for a global note.

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It mentions persistence and cross-session retention, which is useful, but it omits critical behavioral details such as permissions required, whether it creates a new note or updates an existing one, TTL behavior (though the schema hints at it), and any side effects. For a mutation tool, this is a significant transparency gap.

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, well-structured sentence. It front-loads the action ('Create a persistent sticky note') and then provides usage context. There is zero filler or redundancy.

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 5-parameter write tool with no annotations and no output schema, the description is somewhat thin. It explains the purpose and trigger condition, and the schema covers parameter details, but it lacks behavioral context like TTL, lifecycle, and side effects. It is adequate but has clear gaps.

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 input schema already provides 100% coverage with clear descriptions for all five parameters (content, category, tags, importance, project_path). The description adds minimal extra meaning by listing category values (decision, blocker, etc.), but these duplicate the schema enum. With high schema coverage, the 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 uses a specific verb 'Create' and a clear resource 'persistent sticky note', which directly distinguishes it from the sibling tools stickies_read and stickies_dismiss. The phrase 'durable fact emerges' further clarifies the write intent.

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 explicitly states when to use the tool: 'Call this when a durable fact emerges... that future sessions should retain.' It provides clear context and categories of durable facts, but does not mention when not to use it or list alternatives, so it falls short of a 5.

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.

  1. 3 tool updatesv0.13.0
    • First observedstickies_dismiss
    • First observedstickies_read
    • First observedstickies_write

TDQS

A4.2/5.0
Disambiguation5/5

Each tool performs a distinct operation: reading, softening deletion, and creating stickies. No overlap or ambiguity between them.

Naming Consistency5/5

All tools follow a consistent 'stickies_verb' pattern with clear action verbs (read, dismiss, write).

Tool Count5/5

Three tools is well-scoped for a simple sticky-note system, covering the essential operations without bloat.

Completeness5/5

The tool surface covers the full lifecycle of a sticky: create, read, and dismiss. No obvious missing operations for the domain.

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

Related MCP Servers

  • A
    license
    A
    quality
    B
    maintenance
    Cortex is a Claude Code plugin that gives Claude persistent memory across sessions. A background miner extracts durable lessons (decisions, conventions, bug fixes, preferences) from your completed sessions, stores them as markdown in an Obsidian vault, and automatically surfaces relevant ones at the start of each new session via a query-tailored briefing.
    6
    32
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    Persistent memory and task board for Claude Code. 14 tools spanning projects, tasks, sessions, and activity logs — backed by Firestore, runs on the free tier. Handoff notes survive context compaction; the next session reads the last handoff and picks up where you stopped.
    14
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    Enables Claude Code to save, list, and read markdown notes directly from conversations, eliminating manual file management for project ideas, debugging notes, and meeting summaries.
    -

Latest Blog Posts

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/dumbspacecookie/stickies'

If you have feedback or need assistance with the MCP directory API, please join our Discord server