Which integrations are available for this server?

Allows using Google's Gemini models via CLI for natural language task extraction and management. Allows using local Ollama models for natural language task extraction without cloud dependencies. Allows using OpenAI's API (e.g., GPT models) for natural language task extraction and management.

How do I use StickyInc?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@StickyInc add a task to call the dentist this Friday" 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.

StickyInc

by Astralchemist

Overview Schema Related Servers Score Discussions

TypeScript

Local

  ███████╗████████╗██╗ ██████╗██╗  ██╗██╗   ██╗    ██╗███╗   ██╗ ██████╗
  ██╔════╝╚══██╔══╝██║██╔════╝██║ ██╔╝╚██╗ ██╔╝    ██║████╗  ██║██╔════╝
  ███████╗   ██║   ██║██║     █████╔╝  ╚████╔╝     ██║██╔██╗ ██║██║
  ╚════██║   ██║   ██║██║     ██╔═██╗   ╚██╔╝      ██║██║╚██╗██║██║
  ███████║   ██║   ██║╚██████╗██║  ██╗   ██║       ██║██║ ╚████║╚██████╗
  ╚══════╝   ╚═╝   ╚═╝ ╚═════╝╚═╝  ╚═╝   ╚═╝       ╚═╝╚═╝  ╚═══╝ ╚═════╝

           ┌─────────────────────────────────────────────────────────┐
           │  v0.5.2  ·  the subscription-mode release               │
           │                                                         │
           │   ▸ zero-key auto-detect for claude / codex / gemini    │
           │   ▸ Ollama + LM Studio localhost fallback, free         │
           │   ▸ sidebar hidden until setup is done — subtle bulges  │
           │     from the edge on new task / due / setup events      │
           └─────────────────────────────────────────────────────────┘


      ┌──────────────────────────┐        ┌──────────────────────────┐
      │ user ▸ call the dentist  │  MCP   │ ☐ call the dentist       │
      │        friday afternoon  │ ─────▶ │ ☐ email Sarah            │
      │ claude ▸ noted, adding.  │  tool  │ ☑ ship v0.5              │
      └──────────────────────────┘        │ ☐ make it stick          │
                 │                        └──────────────────────────┘
             the chat                               the pane
         evaporates at close           lives in ~/.stickyinc forever

The idea

Every LLM overlay on the market follows the same shape: summon → ask → dismiss. You pop a window, ask a thing, close it, and within an hour the answer has evaporated from your brain and the tab. The model is a disposable oracle; you are the durable storage.

StickyInc inverts that. Chats are cheap and ephemeral; the commitment graph you build from them over months — the promises, deadlines, quiet todos you let slip into conversation — is the part that actually compounds. Nobody was storing it.

So StickyInc does two things, and refuses to do anything else:

  1 ▸ catches the commitments
      ───────────────────────
      when you tell an LLM "call the dentist friday", an MCP tool
      call fires and a checkbox appears on your screen. no
      copy-paste, no "remind me later", no second tab.

  2 ▸ keeps them in front of you
      ──────────────────────────
      an 8-pixel strip lives on the right edge of your screen.
      hover to expand, click to tick off. the file behind it is
      a local SQLite database you own outright — swap LLMs, swap
      laptops, the graph comes with you.

Everything else — chat UI, OAuth flows, cloud sync, a mobile app — is intentionally out of scope. StickyInc is a reification layer. The LLM is the CPU; the pane is the canvas.

Related MCP server: Task Manager MCP Server

Architecture

 ┌──────────────────┐    MCP stdio    ┌──────────────────┐
 │  Claude Desktop  │ ───tool call──▶ │  StickyInc MCP   │
 │   Claude Code    │                 │   (Node, stdio)  │
 │   any MCP host   │                 └────────┬─────────┘
 └──────────────────┘                          │ SQL
                                               ▼
                                 ┌─────────────────────────┐
                                 │ ~/.stickyinc/tasks.db   │
                                 │    (SQLite, yours)      │
                                 └─────────────┬───────────┘
                                               │ notify-rs watcher
                                               ▼
                                    ┌────────────────────┐
                                    │   Pane (Tauri)     │
                                    │ edge-strip, always │
                                    │ on top, translucent│
                                    └────────────────────┘

Claude never talks to the pane directly. They share state through SQLite — one source of truth, nothing to sync, no IPC to break.

Install

Pre-built binaries ship from every tagged release. Signed and notarized builds arrive in v0.6 (see SIGNING.md for the plan).

Platform	File	Notes
macOS (Apple Silicon)	`StickyInc_0.5.1_aarch64.dmg`	ad-hoc signed; Gatekeeper will warn
Windows (x64) — installer	`StickyInc_0.5.1_x64-setup.exe`	NSIS, unsigned — SmartScreen will warn
Windows (x64) — MSI	`StickyInc_0.5.1_x64_en-US.msi`	for group-policy deployment
Linux (Debian/Ubuntu)	`StickyInc_0.5.1_amd64.deb`	`sudo dpkg -i`
Linux (RPM/Fedora)	`StickyInc-0.5.1-1.x86_64.rpm`	`sudo rpm -i`
Linux (portable)	`StickyInc_0.5.1_amd64.AppImage`	`chmod +x` and run

Grab the latest release →

First launch pops a one-minute setup wizard: pick an LLM provider, paste a key, confirm the MCP registration. No terminal commands.

Quickstart

Already have an installer running? Open any Claude Desktop or Claude Code session and say:

I need to call the dentist Friday afternoon.

The task appears in your pane before Claude finishes its reply.

Quick-add without a chat

While the pane is running, press ⌘⇧N (macOS) or Ctrl+Shift+N (Windows/Linux). A centered input appears — type, hit Enter, done. Inline dates work: buy bread due:2026-04-25.

MCP tools

Tool	What it does
`add_task`	Add a todo. Optional `due_at` (ISO date).
`add_task_natural`	Parse free text ("call dentist Friday 3pm") via the configured LLM.
`list_tasks`	Return open tasks; silently appends `Done today (N)` so Claude has state continuity.
`list_done`	Return recently completed tasks, optional archive.
`complete_task`	Mark a task done.
`schedule_event`	Create a dated local task. Calendar sync is deferred to Claude's own connector (see below).

LLM providers

add_task_natural and the passive extraction daemon work with any of:

Provider	How it authenticates	Detected via	Default model
Claude Code — your Claude Max / Pro subscription, no API key	local `claude` CLI OAuth	`claude` on `$PATH`	`haiku`
Codex (ChatGPT) — your ChatGPT Plus / Pro / Team subscription, no API key	local `codex` CLI OAuth	`codex` on `$PATH`	whatever `codex` defaults to
Gemini — your Google account (Gemini Advanced quota or free tier), no API key	local `gemini` CLI OAuth	`gemini` on `$PATH`	whatever `gemini` defaults to
Local (Ollama / LM Studio) — fully offline, free, no cloud call at all	—	`:11434` or `:1234` responding	first installed model
OpenRouter — one key, ~200 models, cheapest per token	API key	`OPENROUTER_API_KEY`	`anthropic/claude-3.5-haiku`
Anthropic (direct)	API key (console.anthropic.com)	`ANTHROPIC_API_KEY`	`claude-haiku-4-5-20251001`
OpenAI (direct)	API key (platform.openai.com)	`OPENAI_API_KEY`	`gpt-4o-mini`
OpenAI-compatible (Groq, Together, Fireworks, vLLM…)	API key	config file	—

Zero-config path

Whatever you already pay for, StickyInc will use it. If any of these are set up on your machine, no key or config is needed:

Claude Code (claude CLI) — bills to your Claude Max / Pro subscription
OpenAI Codex CLI (codex) — bills to your ChatGPT Plus / Pro / Team subscription
Gemini CLI (gemini) — uses your Google account (Gemini Advanced if you have it)
Ollama or LM Studio running locally — fully free, no cloud round-trip

Each subscription CLI call shells out to the tool's print mode (claude -p / codex exec / gemini -p); expect ~1s of subprocess startup per parse. Local-server calls are direct HTTP and cost nothing. Prefer an API key anyway? export OPENROUTER_API_KEY=sk-or-... and it wins over auto-detect.

Resolution priority

  1 · ~/.stickyinc/llm.json   (explicit provider wins)
  2 · OPENROUTER_API_KEY
  3 · ANTHROPIC_API_KEY
  4 · OPENAI_API_KEY
  5 · claude  CLI on PATH    →  Claude Code subscription
  6 · codex   CLI on PATH    →  ChatGPT subscription (via Codex)
  7 · gemini  CLI on PATH    →  Google / Gemini Advanced
  8 · localhost :11434/:1234 →  Ollama / LM Studio

Config file examples — `~/.stickyinc/llm.json`

{ "provider": "claude-code" }

{ "provider": "claude-code", "model": "sonnet" }

{ "provider": "codex" }

{ "provider": "gemini", "model": "gemini-2.5-flash" }

{ "provider": "local" }

{ "provider": "openrouter", "model": "openai/gpt-4.1-mini" }

{ "provider": "anthropic", "model": "claude-sonnet-4-6" }

{ "provider": "compat", "base_url": "http://localhost:11434/v1", "model": "llama3.2", "api_key": "ollama" }

Override the model on any env-var or auto-detect path with STICKYINC_MODEL=….

A note on subscription-mode tradeoffs

Both claude-code and codex providers run a subprocess per call (~500ms–1s of overhead) and share the user's subscription rate limits. For interactive quick-add and the once-per-turn passive daemon this is imperceptible; if you end up in a tight extraction loop, configure a direct API provider instead. Subscription routes also mean StickyInc never touches your auth tokens — they stay in whatever state directory the CLI manages (~/.claude/, ~/.codex/).

Passive extraction (opt-in)

A daemon that tails your Claude Code transcripts and auto-surfaces commitments you mention in passing.

export OPENROUTER_API_KEY=sk-or-...
cd ~/stickyinc && pnpm watch

Watches ~/.claude/projects/**/*.jsonl (Claude Code session files).
For each new user turn (add --assistant to include Claude's turns), calls the configured LLM to extract commitments.
De-dupes via content fingerprint — "call the dentist" won't insert twice if still open.
Ignores hypotheticals and past tense. Empty extractions are free (no DB write).

Privacy: every watched turn is sent to your configured LLM provider. Off by default; you decide when to turn it on.

Calendar — by design, we defer to Claude

StickyInc intentionally doesn't ship its own Google OAuth flow. It's the single hardest setup step in the entire product surface, and Claude Desktop already has a battle-tested Google Calendar connector built in.

When you want a real calendar event, ask Claude in the same turn. schedule_event stores the dated task in StickyInc; Claude creates the calendar entry via its own connector. One less thing for you to set up, one less place your tokens live.

Design axioms

  ┌─ BYO LLM key / subscription ───────────────────────────────┐
  │  no backend, no token costs on our side, no rate-limit     │
  │  theatre. whatever key you already have, we use.           │
  └────────────────────────────────────────────────────────────┘
  ┌─ client-side only ─────────────────────────────────────────┐
  │  conversations never leave your device except to the       │
  │  provider you chose. everything else is local.             │
  └────────────────────────────────────────────────────────────┘
  ┌─ local SQLite ─────────────────────────────────────────────┐
  │  ~/.stickyinc/tasks.db. sync via iCloud / Dropbox /        │
  │  Syncthing if you want. or don't. the file is yours.       │
  └────────────────────────────────────────────────────────────┘
  ┌─ MCP-first ────────────────────────────────────────────────┐
  │  StickyInc doesn't build a chat UI. it's the canvas        │
  │  Claude writes to.                                         │
  └────────────────────────────────────────────────────────────┘
  ┌─ one source of truth ──────────────────────────────────────┐
  │  the DB. pane and MCP both read/write it; no IPC           │
  │  between them; nothing to keep in sync.                    │
  └────────────────────────────────────────────────────────────┘

Dev (running from source)

git clone https://github.com/Astralchemist/stickyinc
cd stickyinc
pnpm install
pnpm dev              # MCP server (stdio)

# in another terminal
cd pane
pnpm install
pnpm tauri:dev        # pane (edge-strip, always on top)

Linux dev deps (Ubuntu 22.04+):

sudo apt-get install -y \
  libwebkit2gtk-4.1-dev libgtk-3-dev libayatana-appindicator3-dev \
  librsvg2-dev libxdo-dev libssl-dev build-essential curl wget file

macOS and Windows need only Rust + Node. Release builds run through GitHub Actions — see .github/workflows/build.yml.

How the pane actually works

Always-on-top, transparent, frameless, skipTaskbar. 8px strip glued to the right edge by default.
Hover → window resizes to 320px, pane slides in. Click-through everywhere else.
Checkbox click → Rust complete_task command → SQLite UPDATE → notify-rs watcher emits tasks-changed → UI re-fetches.
Red dot on the strip when any open task is past its due_at.
Reads/writes the same ~/.stickyinc/tasks.db as the MCP server. One source of truth.

Roadmap

  [x] v0.1     MCP server, SQLite, four tools.
  [x] v0.2     Tauri edge-strip pane.
  [x] v0.3     Recently-done + Archive drawer, list_done, CI,
               LLMProvider (Anthropic + OpenRouter + OpenAI-compat),
               add_task_natural.
  [x] v0.4     Passive extraction daemon, fingerprint dedup,
               done-today feedback in list_tasks.
  [x] v0.5     Global ⌘⇧N quick-add window, full icon set,
               one-click setup wizard, tagged release builds
               for macOS / Windows / Linux.
  [x] v0.5.1   Subscription-mode providers (Claude Code, Codex,
               Gemini, Ollama/LM Studio) with zero-key auto-detect.
               Sidebar hidden until setup is done — subtle bulge
               notifications for new tasks, due crossings, and
               incomplete setup.

  [ ] v0.6     ▸ in-app auto-updater (check + download + install
                 signed bundles on launch; users never miss a fix)
               ▸ wizard reworked to detect claude / codex / gemini
                 CLIs and offer zero-key "use my subscription" as
                 the default; API key becomes the fallback, not
                 the front door
               ▸ signed + notarized macOS installer, signed MSI on
                 Windows (see SIGNING.md)
               ▸ UUID task IDs + append-only event log — unlocks
                 multi-device sync, undo, and audit history. Done
                 on desktop regardless of mobile, because the
                 migration is scary later and free now.

  [ ] v0.7     ▸ phone access without an app: desktop pane serves
                 a read-only LAN web view over HTTPS — bookmark
                 it on your phone, no store review, no sync engine
               ▸ per-project tasks (separate DBs per Claude Code
                 workspace), weekly digest, menu-bar quick-add

  [ ] v0.8+    ▸ native mobile (Tauri 2 iOS + Android) — viewer,
                 quickadd, share-sheet, voice capture via Siri /
                 Assistant Shortcuts
               ▸ LAN sync over mDNS + self-signed TLS + QR
                 pairing (LocalSend-style). No relay, no backend.
                 Filesystem sync (iCloud / Dropbox / Syncthing)
                 remains the documented "away from home" path.

License

MIT. Do what you want.

Available Tools

6 tools

add_taskAdd TaskA

Add a todo to StickyInc. The user sees it appear in their floating pane.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	The task text, e.g. 'Call the dentist'
`due_at`	No	Optional ISO 8601 datetime when this is due, e.g. '2026-04-24T15:00:00Z'

TDQS

A3.6/5.0

Behavior3/5

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

No annotations provided; description includes the effect of immediate UI appearance, but lacks details on side effects, limits, or error handling.

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 efficient sentences with front-loaded purpose and behavioral context, no 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 2-param tool with no output schema; covers purpose and key effect, though missing error or limit info.

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 has 100% coverage with descriptions for both parameters; description adds no extra meaning beyond schema examples.

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 verb 'Add', resource 'todo to StickyInc', and user-facing effect 'appears in floating pane'. Distinct from sibling add_task_natural.

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 vs alternatives like add_task_natural or when prerequisites apply.

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

add_task_naturalAdd Task (natural language)A

Parse a free-text phrase like 'call dentist Friday 3pm' into a task with optional due date, using the configured LLM (Anthropic/OpenRouter/OpenAI).

ParametersJSON Schema

Name	Required	Description	Default
`input`	Yes	Free-text phrase like 'call dentist Friday 3pm' or 'buy bread'. Will be parsed by the configured LLM.

TDQS

A3.5/5.0

Behavior2/5

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

Mentions LLM usage but omits crucial behavior: whether it actually creates the task or just returns parsed data, error handling, side effects. No annotations to supplement.

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 examples and provider context, no filler.

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 one-param tool, description is mostly adequate but lacks return value and error expectations, making it slightly incomplete.

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 covers 100% of parameters with description. Description adds LLM parsing context but doesn't significantly improve understanding beyond 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?

Clearly states it parses free-text into a task with optional due date using an LLM. Distinguishes from sibling 'add_task' which likely uses structured input.

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?

Implies usage when natural language input is available, but no explicit when-to-use or when-not-to-use guidance, nor mention of alternatives.

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

complete_taskComplete TaskA

Mark a StickyInc task done by id.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	The task id to mark complete

TDQS

A3.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 must fully disclose behavior. It indicates a mutation (mark done) but does not mention side effects, permissions required, success/failure behavior, or whether the action is reversible. The transparency 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?

The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the tool's purpose.

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 nearly complete. It could add minor details about behavior (e.g., what happens on success/failure), but it covers the essential action.

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 baseline is 3. The description adds no extra meaning beyond the schema's parameter description ('The task id to mark complete'). It does not compensate or provide additional context.

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 ('mark done'), the resource ('StickyInc task'), and the method ('by id'). It distinguishes from sibling tools like add_task, list_tasks, etc., which perform different operations.

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 when a task needs to be marked complete, but it provides no explicit guidance on when to use this tool versus alternatives or any prerequisites. The context is implied rather than stated.

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

list_doneList DoneA

List recently completed StickyInc tasks, with optional archive of older completions.

ParametersJSON Schema

Name	Required	Description	Default
`hours`	No	Show tasks completed within the last N hours. Default: 24.
`include_archive`	No	Also include older completions (up to 100 rows). Default: false.

TDQS

A3.6/5.0

Behavior2/5

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

No annotations exist, so description must bear full burden. It only hints at read-only behavior by 'list' verb but does not disclose any traits beyond what is in the schema (e.g., read-only, auth, rate 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?

Single sentence of 12 words, front-loaded with key information. Every part is necessary and no 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?

For a simple list tool with two optional parameters and no output schema, the description covers the essential behavior. Could mention default time window or result limits, but overall adequate.

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 covers 100% of parameters with clear descriptions for 'hours' and 'include_archive'. Description merely echoes 'recently completed' and 'optional archive', adding no extra meaning 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?

Description clearly states verb 'list', resource 'completed tasks', and scope 'recently' with optional archive. It distinguishes from siblings like 'list_tasks' and 'complete_task' by focusing on done tasks.

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 comparison to sibling tools or conditions for use. Agent must infer that this is for completed tasks, but no when-not or alternative guidance is provided.

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

list_tasksList TasksB

List open StickyInc tasks (or all, with include_completed=true).

ParametersJSON Schema

Name	Required	Description	Default
`include_completed`	No	If true, include completed tasks. Default: false (open tasks only).
`limit`	No	Max number of rows when include_completed is true. Default: 50.

TDQS

B3.4/5.0

Behavior3/5

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

Without annotations, the description carries the burden. It discloses the effect of 'include_completed' and 'limit' on results, which adds some behavioral context. However, it omits details like ordering, pagination, or idempotency, leaving the agent with 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?

Two sentences with no wasted words. The description is front-loaded with the core behavior and effectively uses a parenthetical for the key parameter. It earns its place.

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 list tool with zero required parameters and no output schema, the description covers the essential behavior. However, it lacks details on ordering, error conditions, or connection to siblings like 'list_done', leaving some contextual gaps.

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%, so baseline is 3. The description adds value by explaining 'include_completed' switches between open and all tasks, and clarifies that 'limit' applies only when include_completed is true, enhancing understanding beyond the schema.

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 lists tasks, specifying the default behavior (open tasks) and the parameter to include completed tasks. It distinguishes the tool's scope from siblings like 'add_task', but does not explicitly differentiate from 'list_done'.

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?

There is no explicit guidance on when to use this tool versus alternatives like 'list_done' or 'complete_task'. The description implies usage for listing tasks but fails to provide exclusion criteria or when-not-to-use.

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

schedule_eventSchedule EventB

Schedule an event. v0.1 stores as a dated task; v0.3 will call Google Calendar create_event.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Event title
`start`	Yes	ISO 8601 start datetime, e.g. '2026-04-24T15:00:00Z'
`end`	No	ISO 8601 end datetime (optional)
`notes`	No	Optional notes/description

TDQS

B3.4/5.0

Behavior4/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 discloses current behavior (stores as dated task) and future plan (Google Calendar integration), which adds value beyond the schema. However, it does not mention authorization needs, side effects, or what happens on conflict.

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 concise with two sentences, front-loading the core purpose. Every sentence adds value, though the version note could be placed more prominently. No wasted words.

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, the description lacks information about return values or confirmation. The versioning context is helpful, but the tool's overall behavior (e.g., what the agent receives after scheduling) is missing. Adequate but not fully complete.

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% with good descriptions for all parameters. The description adds no parameter-specific information beyond the schema, so the baseline of 3 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?

The description clearly states the tool schedules an event, with a specific verb and resource. The version note adds context about current vs future behavior, but it doesn't explicitly distinguish from sibling tools like add_task, which also deals with tasks.

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. The description implies it's for scheduling events (currently stored as dated task) but offers no exclusions or direct comparison to siblings (add_task, complete_task, etc.).

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation4/5

Most tools have clearly distinct purposes: add_task vs add_task_natural differ in input method, list_done vs list_tasks separate completed from open items, and schedule_event is unique. Slight overlap between add_task and add_task_natural but descriptions clarify.

Naming Consistency4/5

Tools mostly follow a verb_noun pattern (add_task, complete_task, list_done, list_tasks, schedule_event). The exception is add_task_natural, which adds a qualifier but still consistent in style. No mixing of conventions.

Tool Count5/5

With 6 tools, the server is well-scoped for a focused task management assistant. Each tool addresses a core operation without unnecessary bloat or excessive specialization.

Completeness3/5

Basic create (add tasks), read (list tasks/done), and update (mark done) are covered, but missing update/edit task, delete task, and event scheduling is still immature (v0.1). Gaps may cause agent failures for common workflows.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

CalmLoop Task Manager
in.calmloop
Manage tasks, Focus Zone, notes, projects, and task history from compatible AI assistants.
Project Management Note Taking
1
Bubbl
io.github.bubbl-ai
AI teammate for tasks: builds your list from meetings, email and chats, and checks off done work.
Project Management App Automation Workplace & Productivity
2
Done Bear A
com.donebear
Local-first task manager: create, edit, and complete tasks, projects, and checklists via MCP.
Project Management App Automation
351
Superlist
io.github.superlistapp
Manage Superlist tasks and lists in plain language from any MCP-compatible AI agent.
Project Management Workplace & Productivity
2

Related MCP Servers

Claude Todo MCP Server
Coding Agents Autonomous Agents Developer Tools
joehaddad2000
A
license
B
quality
D
maintenance
Adds persistent task management to AI coding assistants in IDEs, allowing them to track multi-step tasks across sessions and maintain organized workflow with project-scoped todo lists.
Updated 9 months ago (2025-11-21 21:43 UTC)
2
26
MIT
Task Manager MCP Server
App Automation Workplace & Productivity Project Management
MyLightIsOn
F
license
Not graded
quality
D
maintenance
Enables task management through natural language with full CRUD operations including add, list, update, complete, and delete tasks with JSON persistence.
Updated 8 months ago (2025-12-25 03:14 UTC)
Todo MCP Server
Project Management
X4MU-L
A
license
A
quality
D
maintenance
Enables AI assistants to manage a todo list with add, list, complete, and delete tasks.
Updated 8 months ago (2026-01-05 16:34 UTC)
4
18
MIT
commitment-tracker-mcp
Knowledge & Memory Project Management
ritheshr21
F
license
Not graded
quality
B
maintenance
Tracks commitments (promises made in conversations) and provides tools to add, list, mark as fulfilled, and check overdue items.
Updated 2 months ago (2026-07-06 20:29 UTC)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Astralchemist/stickyinc'

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

The idea

Architecture

Install

Quickstart

Quick-add without a chat

MCP tools

LLM providers

Zero-config path

Resolution priority

Config file examples — ~/.stickyinc/llm.json

A note on subscription-mode tradeoffs

Passive extraction (opt-in)

Calendar — by design, we defer to Claude

Design axioms

Dev (running from source)

How the pane actually works

Roadmap

License

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Config file examples — `~/.stickyinc/llm.json`