Which integrations are available for this server?

Integrates with Apple Reminders to read tasks from specified lists, enabling AI to check, search, and manage reminders on macOS. Integrates with GitHub Issues to read and manage issues assigned to the user, providing tools for listing, creating, and updating tasks. Integrates with Linear to read and manage issues assigned to the user, supporting full CRUD operations on tasks. Integrates with Notion databases to manage tasks, including reading, creating, and updating items with properties like name, done, due, priority, and tags. Integrates with Todoist using the REST API to read and write tasks, enabling full management of todos.

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., "@nudge what's due today?" 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.

nudge

by davesleal

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

nudge

npm version License: MIT MCP

Your AI assistant, acting like a friend who actually remembers what you said you'd do.

nudge is an open-source Model Context Protocol (MCP) server that connects Claude — or any MCP-compatible AI — to your todo app. Instead of a cold productivity dashboard, you get a friend checking in naturally.

"hey, you've had 'call the accountant' on your list for 4 days 👀"
"nothing due today, you're all clear"
"added 'dentist appointment' for Friday"

No server to run. No first-person AI narration. Just a nudge.

Install

Quickest — setup wizard

npx nudge-mcp-init

Walks you through picking your todo app, entering credentials, and wiring up Claude Desktop automatically. Done in under a minute.

Manual — Claude Desktop (no server needed)

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "nudge": {
      "command": "npx",
      "args": ["nudge-mcp"]
    }
  }
}

Restart Claude Desktop. That's it — Claude now has access to your tasks and will bring them up naturally.

Claude Desktop launches nudge as a subprocess. Nothing runs in the background when you're not using Claude.

Global install

npm install -g nudge-mcp
nudge-mcp

No install (try it)

npx nudge-mcp

Related MCP server: Todoist MCP Server

Supported backends

App	Config type	Notes
Local JSON file	`local`	Default — zero config needed
Markdown checklist	`local`	Any `- [ ] task` format
Todoist	`todoist`	Full read + write via REST API
Notion	`notion`	Read + write via database
Linear	`linear`	Issues assigned to you, full read + write
GitHub Issues	`github`	Issues assigned to you, full read + write
Apple Reminders	`reminders`	macOS only — no API key, reads directly
Anything else	`local`	Sync/export to a JSON or `.md` file

Want to add an adapter? See CONTRIBUTING.md.

Configuration

Create ~/.nudge/config.json — or skip it entirely to use the zero-config local default.

Local JSON (default — no config file needed)

Tasks live at ~/.nudge/todos.json:

[
  { "id": "1", "title": "Call the accountant", "done": false, "due": "2026-03-03", "priority": "high" },
  { "id": "2", "title": "Buy birthday gift",   "done": true },
  { "id": "3", "title": "Dentist appointment", "done": false, "tags": ["health"] }
]

Markdown checklist

{
  "adapter": { "type": "local", "filePath": "~/Documents/tasks.md", "format": "markdown" }
}

- [ ] Call the accountant
- [x] Buy birthday gift
- [ ] Dentist appointment

Todoist

{
  "adapter": { "type": "todoist", "apiKey": "your_token_here" }
}

Or set the env var: TODOIST_API_KEY=your_token npx nudge-mcp

Get your token: Todoist → Settings → Integrations → Developer

Notion

{
  "adapter": {
    "type": "notion",
    "apiKey": "secret_xxx",
    "databaseId": "your_database_id"
  }
}

Your database needs: Name (title), Done (checkbox), and optionally Due (date), Priority (select: Low / Medium / High), Tags (multi-select).

Setup: create an internal integration at notion.so/my-integrations, then share your database with it.

Apple Reminders

{
  "adapter": {
    "type": "reminders",
    "list": "To Do"
  }
}

No API key needed — reads directly from the Reminders app via AppleScript. macOS only.

list is optional. If omitted, nudge reads all lists. If you have a lot of reminders or multiple iCloud accounts, specifying a list is faster and more reliable.

Troubleshooting:

First run — macOS will prompt for Automation permission. Click Allow when asked, or go to System Settings → Privacy & Security → Automation and enable Reminders for your terminal.
iCloud sync issues — if you get a "Can't get" error, open Reminders.app and wait for it to fully sync before trying again.
Timeouts with large lists — add "list": "To Do" (or whichever list you use most) to your config to limit the scope.
List name must match exactly — including capitalisation. Run osascript -e 'tell application "Reminders" to get name of every list' in Terminal to see your exact list names.

Tools

nudge exposes these tools to any connected AI:

Tool	What it does
`check_tasks`	"Did I ever call the dentist?" — fuzzy matched
`get_pending_today`	What's still open and due today
`list_todos`	Full list, with filters (overdue, tag, priority, done)
`get_stats`	Honest summary — done, pending, overdue
`search_todos`	Find tasks by keyword
`create_todo`	"Remind me to call Dave on Friday" → adds it
`mark_complete`	"Done with the report" → ticks it off
`mark_incomplete`	"Actually I didn't finish that" → reopens it

nudge also ships a suggested system prompt (as an MCP prompt resource named nudge-persona) that gives the AI the right tone: warm, honest, not preachy. Claude Desktop can pick this up automatically.

Connecting apps without a native adapter

Apple Shortcuts — build a shortcut that exports tasks as JSON to ~/.nudge/todos.json on a schedule.

Zapier / Make — add a step that writes task updates to the file whenever something changes in your app.

Obsidian / Logseq — point filePath at your daily note and use format: "markdown".

Any CLI app — add a cron: 0 * * * * myapp export --format json > ~/.nudge/todos.json

Writing a new adapter

Each adapter is a single file in src/adapters/. Implement two required methods and you're done:

import { Todo, NewTodo, TodoAdapter } from "../types.js";

export class MyAppAdapter implements TodoAdapter {
  name = "myapp";

  async listTodos(): Promise<Todo[]> {
    // fetch from your app's API
    return [];
  }

  async getTodo(id: string): Promise<Todo | null> {
    return null;
  }

  // Optional — enables create_todo tool
  async createTodo(input: NewTodo): Promise<Todo> { ... }

  // Optional — enables mark complete/incomplete
  async markComplete(id: string): Promise<void>   { ... }
  async markIncomplete(id: string): Promise<void> { ... }
}

Then register it in src/index.ts in buildAdapter(). See CONTRIBUTING.md for the full guide.

Roadmap

nudge init — interactive setup wizard
Apple Reminders adapter (macOS, via AppleScript)
Linear adapter
GitHub Issues adapter
mark_complete / mark_incomplete tools
Asana / Microsoft To Do adapter
Webhook listener for real-time push (tasks trigger the AI)
Scheduled nudge mode (daily check-in without opening Claude)

Contributing

PRs and issues are welcome — especially new adapters. See CONTRIBUTING.md.

License

MIT © Dave Leal

Available Tools

8 tools

check_tasksA

Check whether specific things have been done. Fuzzy-matches task names so you don't need exact wording. Great for friendly check-ins: 'did you ever call the dentist?' Use this when the user mentions something they said they'd do and you want to see if it's on the list and whether it's ticked off.

ParametersJSON Schema

Name	Required	Description	Default
`names`	Yes	Things to check on. Fuzzy matched — 'dentist' will find 'Call the dentist'.

TDQS

A4/5.0

Behavior3/5

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

Discloses fuzzy matching and that it checks completion status. No annotations provided, so description carries burden. Lacks details on behavior for non-existent tasks or multiple matches, but adequate for a simple tool.

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

Conciseness5/5

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

Two sentences, zero waste. Purpose is front-loaded. Efficient and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given low complexity (1 param, no output schema), description covers key aspects: purpose, matching behavior, typical use case. Could mention return format but not essential.

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?

Only one parameter 'names' with 100% schema coverage. Description reinforces fuzzy matching but adds limited new semantics beyond schema. Baseline 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?

Clearly states it checks whether specific things have been done, with fuzzy matching. Distinguishes from sibling tools like search_todos and list_todos by emphasizing the checking 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?

Explicitly describes when to use: when user mentions something they said they'd do and want to see if it's on the list and ticked off. Provides example usage. Lacks explicit when-not-to-use but context with siblings implies it.

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

create_todoA

Add a new task to the user's list. Use this when the user says something like 'remind me to...' or 'add X to my list' or 'I need to do Y by Friday'. Confirm what you added so they know it landed.

ParametersJSON Schema

Name	Required	Description
`due`	No	Due date in YYYY-MM-DD format. Infer from natural language if possible.
`tags`	No	Optional labels or categories.
`notes`	No	Any extra context or details for the task.
`title`	Yes	The task title. Keep it clear and action-oriented.
`priority`	No	How urgent is this?

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 alone must disclose behavioral traits. It only states the creation action and hints at confirmation, but omits important details like side effects, idempotency, permissions, 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?

The description is very concise: two sentences plus usage examples, all front-loaded and to the point. Every sentence adds value, avoiding any fluff 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?

Given 5 parameters, no output schema, and sibling tools, the description covers when to use and what to do after, but lacks explanation of return values (e.g., what 'confirm' means) or error scenarios, making it slightly incomplete for a creation tool.

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 the schema already documents all parameters well. The description adds no new parameter information beyond the usage examples, which slightly reinforces the schema but does not significantly enhance understanding.

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 'Add a new task to the user's list' with specific verb and resource. It provides concrete usage examples and distinguishes from sibling tools (e.g., list_todos, mark_complete) by focusing on creation.

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 tells when to use the tool ('when user says remind me...') and advises confirming the action. However, it does not mention when not to use it or suggest alternative sibling tools for different scenarios.

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

get_pending_todayA

See what's still on the user's plate for today — useful for a natural mid-day or end-of-day check-in. If it's getting late and there are still open tasks, that's worth a gentle mention.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/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 behavioral traits. It implies read-only behavior but does not explicitly state side effects, permissions, or rate limits. The hint about "gentle mention" adds some context but insufficient detail for complete transparency.

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 zero wasted words. The purpose is front-loaded and the use case follows immediately. Every sentence 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 tool with no parameters and no output schema, the description covers the purpose and a usage scenario. However, it lacks detail on the exact return value (list of tasks? counts?) and how it differs from list_todos. Some gaps remain for full context.

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, and schema coverage is 100%. The description does not need to explain parameters, and it adds no conflicting information. Baseline 4 is appropriate for a no-parameter tool.

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

Purpose5/5

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

The description clearly states the tool's function: "See what's still on the user's plate for today". It uses a specific verb-noun pair (see pending tasks) and differentiates from siblings like list_todos by focusing on today's items. The use case (mid-day or end-of-day check-in) adds specificity.

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 advises using this tool for "natural mid-day or end-of-day check-in" and hints at agent behavior ("worth a gentle mention"). However, it does not explicitly state when not to use it or compare to alternatives like list_todos or check_tasks.

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

get_statsA

Get an honest summary of where things stand: total tasks, done today, pending, overdue. Use this for an end-of-day check-in or when the user wants the big picture.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/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. It clearly states that the tool returns a summary of counts (total tasks, done today, pending, overdue), which is transparent for a read-only aggregation tool. No side effects or additional behavior is needed given the simplicity.

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 first sentence immediately states the purpose and key outputs, and the second provides use-case guidance. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description covers the essential information. It provides enough context for the agent to know when to use it versus siblings. However, it could more precisely define terms like 'done today' (e.g., tasks completed today vs. created today).

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

Parameters5/5

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

The tool has zero parameters, so the schema is fully covered (100%). The description adds value by explaining the nature of the output without needing to detail any inputs. This exceeds the baseline requirement.

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 verb 'Get' and the resource 'summary of where things stand', listing specific data points (total tasks, done today, pending, overdue). This distinguishes it from siblings like list_todos (which lists individual tasks) and get_pending_today (which focuses on pending tasks only).

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 recommends using this tool for 'an end-of-day check-in or when the user wants the big picture,' providing clear usage context. However, it does not mention when not to use it or name alternative tools explicitly, though the purpose differentiation is implied.

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

list_todosB

List the user's tasks with optional filters. Use this when asked directly, or when you need context to give a useful, honest answer about where things stand.

ParametersJSON Schema

Name	Required	Description
`tag`	No	Filter by a specific tag or label.
`done`	No	true = completed only, false = pending only. Omit for all.
`overdue`	No	Only tasks past their due date and still open.
`priority`	No
`due_today`	No	Only tasks due today.

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Only states it lists with filters, with no disclosure of read-only nature, return format, or side effects. Agents lack important behavioral context.

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, directly front-loaded with action and filters. No wasted words; every sentence serves a purpose.

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?

With 5 optional parameters, no output schema, and no annotations, the description is too sparse. It omits details on default behavior (e.g., returns all tasks if no filters), ordering, or pagination, leaving agents underinformed.

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 80%, so description does not need to add much. The description merely says 'optional filters', adding no extra meaning beyond what the schema already provides for parameters.

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?

Clearly states 'List the user's tasks with optional filters', which specifies the verb and resource. Does not explicitly differentiate from siblings like search_todos or get_pending_today, but the primary purpose is clear.

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?

Says 'Use this when asked directly, or when you need context to give a useful, honest answer about where things stand', which provides some usage context but no exclusions or comparisons with alternatives.

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

mark_completeA

Mark a task as done. Use this when the user says 'done', 'finished', 'crossed that off', or anything that means they completed something. Fuzzy-match the name first with check_tasks if you're not sure of the exact ID. Celebrate appropriately — one line is enough.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No	The task ID to mark complete.
`name`	No	Task name to fuzzy-match if you don't have the ID.

TDQS

A4/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 full burden. It only states that it marks a task as done and suggests celebrating, but does not disclose potential side effects (e.g., irreversible action? requires write permissions?), prerequisites, or how task state changes. Minimal behavioral context beyond the obvious.

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?

Three sentences, each front-loaded with key info: purpose, usage trigger, and a brief behavior note. The celebration remark is slightly extraneous but harmless. No filler, but could be tightened.

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 mutation tool with 2 parameters and no output schema, the description covers the core use case, when to use it, and how to resolve ambiguity. It does not describe return values, but that is acceptable given the lack of output schema. Minor missing info on success/failure indicators.

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

Parameters5/5

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

Schema coverage is 100%, and the description adds significant value: it explains the purpose of each parameter (id vs name for fuzzy-matching) and suggests using check_tasks to find the correct ID. This goes beyond the schema's own descriptions.

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 'Mark a task as done' and provides specific trigger phrases (done, finished, crossed that off). It explicitly distinguishes itself from sibling tools like mark_incomplete and gives context for when to use it.

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?

Explicit when-to-use guidance is given (user says completion phrases) and a pre-step is recommended (fuzzy-match with check_tasks). It does not explicitly mention when not to use, but the positive guidance is clear and actionable.

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

mark_incompleteA

Reopen a task that was marked done. Use when the user says something like 'actually I didn't finish that' or 'reopen X'.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No	The task ID to reopen.
`name`	No	Task name to fuzzy-match if you don't have the ID.

TDQS

A4.3/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 burden. It states the tool reopens a task, which is a simple state change. The behavior is straightforward and adequately disclosed.

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, front-loaded with the main action. No unnecessary words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, two simple parameters, and sibling tools, the description is complete: it explains the action, when to use, and parameters are fully described in the schema.

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 clear descriptions. The tool description adds minimal parameter info beyond the schema, only reinforcing usage context. Baseline 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 clearly states the tool reopens a task marked done, using a verb and resource. It includes example user utterances to clarify intent. It distinguishes from the sibling tool 'mark_complete' which does the opposite.

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 says 'Use when the user says something like...' providing practical usage context. It implicitly distinguishes from alternatives but does not explicitly state 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.

search_todosB

Search across task titles and notes by keyword.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Keyword to search for.

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It lacks disclosure of behavioral traits such as case sensitivity, exact matching, pagination, or whether it returns only matching tasks. Minimal transparency.

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 zero wasted words. Every word 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 tool with one parameter, the description is adequate but could mention output or search behavior. Lacks details like return format or search algorithm, but schema and simplicity keep it minimally 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 description coverage is 100% with a clear description for 'query'. The tool description adds no additional meaning beyond what the schema provides. Baseline score 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 clearly states the action (search) and the scope (task titles and notes by keyword). It distinguishes from sibling tools like list_todos which lists all tasks without filtering.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like check_tasks or list_todos. The description only states what it does, not when it's appropriate or when not to use it.

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.

8 tool updatesv1.0.2Jul 12, 2026
- First observedcheck_tasks
- First observedcreate_todo
- First observedget_pending_today
- First observedget_stats
- First observedlist_todos
- First observedmark_complete
- First observedmark_incomplete
- First observedsearch_todos

Install Server

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

TDQS

A3.9/5.0

Disambiguation4/5

Tools are mostly distinct but check_tasks and search_todos overlap in searching, and list_todos with filters overlaps with get_pending_today and get_stats, causing mild ambiguity.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., create_todo, mark_complete), making them predictable and easy to distinguish.

Tool Count5/5

With 8 tools, the set is well-scoped for a task management assistant, covering core operations without being overwhelming.

Completeness4/5

The set covers CRUD operations except for task deletion, and lacks editing capabilities, but the core lifecycle (create, read, update status) is present.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

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

Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
214
mcpOAuth
net.todoist
Official Todoist MCP server for AI assistants to manage tasks, projects, and workflows.
App Automation Workplace & Productivity Project Management
2
ZapierOAuth
com.zapier
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
App Automation Workplace & Productivity
2297
hjarni AOAuth
com.hjarni
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
Note Taking Workplace & Productivity
3

Related MCP Servers

Todoist MCP Server
App Automation Project Management
abhiz123
A
license
A
quality
C
maintenance
An MCP server that integrates Claude with Todoist, enabling natural language task management including creating, updating, completing, and deleting tasks.
Updated a year ago (2025-04-20 04:03 UTC)
5
554
392
MIT
Todoist MCP Server
Project Management App Automation
greirson
A
license
B
quality
C
maintenance
An MCP server that connects Claude with Todoist for complete task and project management through natural language.
Updated 4 months ago (2026-05-01 10:23 UTC)
86
184
243
MIT
Things MCP Server
App Automation Project Management OS Automation
wbopan
A
license
A
quality
C
maintenance
An MCP server that allows AI assistants like Claude Code, Claude Desktop, and Cursor to interact with Things.app on macOS, enabling task creation, updates, viewing, scheduling, and organization through natural language.
Updated 9 months ago (2025-12-20 04:02 UTC)
6
24
3
MIT
Personal Toolkit MCP Server
Developer Tools App Automation
SANDEEP-KR-MAHTO
F
license
Not graded
quality
D
maintenance
A local MCP server providing text utilities, math functions, and a persistent todo list, enabling task automation via natural language in Claude Desktop.
Updated 3 months ago (2026-06-13 07:18 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/davesleal/nudge'

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