AI Note MCP Server
The AI Note MCP Server enables AI assistants to seamlessly manage your AI Note task management system through natural language commands.
Core Capabilities:
Task Management: Create, update, soft delete, and list tasks with support for content, importance levels, due dates (ISO format), completion status, and category assignments
Advanced Filtering: Search tasks by content keywords, filter by status (pending/completed), and limit results
Category Management: List available categories and organize tasks accordingly
Priority System: Mark tasks as important and manage priority levels
Integration Methods:
stdio Mode: Direct integration with Claude Desktop and other stdio-based MCP clients
Local SSE Bridge: Expose tools to ChatGPT and SSE-capable clients without deploying infrastructure
Hosted HTTP Endpoint: Platform integrations (e.g., Kakao PlayMCP) and custom applications requiring direct API access
Security & Compatibility:
API key authentication with optional OAuth bearer token support
Cross-platform compatibility with Claude Desktop, ChatGPT, and other MCP-compatible platforms
Provides a Node.js-based MCP server implementation for AI Note integration, supporting task management with categories, search, priority management, and due date features.
Allows installation and distribution of the AI Note MCP server package through npm registry, making it easily accessible for Claude Desktop users.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@AI Note MCP Serveradd 'schedule team meeting for Friday' to my tasks"
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.
AI Note MCP Server
A Model Context Protocol (MCP) server that connects AI assistants to your AI Note task management system. This package enables direct interaction with your AI Note tasks through natural language conversations in Claude Desktop and other MCP-compatible platforms.
š Complete Project Guide - ģ 첓 ķė”ģ ķø ź°ģ“ė ė° ģķ¤ķ ģ² ģ 볓
Table of Contents
Related MCP server: MCP TaskManager
Access Methods
AI Note MCP server is available through three transport options to cover different integration scenarios:
1. stdio Mode (This Package) - For Personal Use
Installation:
npm install -g @ainote/mcpUsage: Claude Desktop and other stdio-based MCP clients
Setup: Local installation with API key configuration
Best for: Individual users connecting their personal AI Note account to Claude Desktop
2. Local SSE Bridge (ChatGPT / MCP Apps)
Command:
ainote-mcp-httpProtocol: Server-Sent Events (SSE) + JSON-RPC over HTTP POST
Usage: ChatGPT Model Context Protocol connectors, other SSE-capable MCP clients
Setup: Run locally alongside your browser; supports API key or (optional) OAuth bearer tokens
Best for: Users wanting to expose AI Note tools to ChatGPT without deploying infrastructure
3. Hosted HTTP Endpoint - For Platform Integration
URL:
https://api.ainote.dev/api/mcpProtocol: JSON-RPC 2.0 over HTTP
Usage: Platform integrations (Kakao PlayMCP, etc.)
Setup: No installation required, direct API access
Best for: Third-party platforms and services integrating AI Note functionality
All transports expose the same tool catalog. Choose the option that matches your hosting model and client capabilities.
Features
š Task Management: Create, update, delete, and list tasks directly from Claude Desktop
š Dev Docs: Manage CLAUDE.md, Cursor rules, Windsurf rules, and dev documents centrally via MCP
šļø Dev Category Hierarchy: Auto-organized under
dev/with subcategories (claude, cursor, windsurf, copilot, docs, skills, agents, commands, hooks, mcp)š Claude Environment Sync: Push/pull
~/.claude/skills, agents, commands, hooks across machines (macOS/WSL/Linux)š End-to-End Encryption:
mcpcategory (mcpServers + API keys) auto-encrypted client-side with age; server never sees plaintextšŖŖ OS Keychain Integration: Per-machine age identity stored in macOS Keychain / libsecret / Credential Manager (file fallback supported)
š¤ Session Handoffs:
handoff_save/handoff_list/handoff_getwith optionaltime: HHMMfor same-day disambiguation ā saved under the primary vault, auto-purged after 7 daysš¦ Multi-Device File Sync:
sync_push/sync_pull/sync_listpush markdown notes into the user's git-backed primary vault ā works across macOS, Linux, iOS shortcutsšļø GitHub-Backed Vaults:
vault_create/vault_clone/vault_syncprovision a private GitHub repo per vault; ainote indexes contents but never proxies git trafficš”ļø MCP Tool Annotations: Every tool advertises
readOnlyHint/destructiveHint/idempotentHint/openWorldHintso autonomous agent runtimes can gate destructive callsš·ļø Category Support: Organize tasks with categories
š Advanced Filtering: 18+ filter options including date ranges, location, overdue tasks
ā Priority Management: Mark tasks as important
š Smart Due Dates: Human-readable format with relative time (e.g.,
'26.1.25 14:30 - ģ¤ė)š Dual Authentication: Support for both User API Key (24-char) and MCP Key (64-char)
š Usage Tracking: Automatic API usage statistics per MCP key
š Streaming API: Real-time streaming for bulk operations and large datasets
š¤ Bot Integration: Telegram bot support via Clawdbot + mcporter
Quick Start (No Account Needed)
You can start using AI Note MCP without an existing account. The MCP server includes onboarding tools that let you sign up and get an API key directly from Claude:
1. Add to your MCP config (no API key yet)
{
"mcpServers": {
"ainote": {
"command": "npx",
"args": ["-y", "@ainote/mcp"]
}
}
}2. Restart Claude Desktop
3. Ask Claude to sign you up
"Sign me up for AI Note with email user@example.com and password mypassword123"
Claude will call the signup_and_get_key tool and return your MCP API key.
4. Add the API key to your config
{
"mcpServers": {
"ainote": {
"command": "npx",
"args": ["-y", "@ainote/mcp"],
"env": {
"AINOTE_API_KEY": "<your-key-from-step-3>"
}
}
}
}5. Restart Claude Desktop again
Now all tools (tasks, dev docs, etc.) are available.
CLI Signup
You can also sign up directly from the terminal:
npx @ainote/mcp signupThis will interactively ask for email, password, and name, then return your MCP API key.
CLI Tool Invocation (call)
Run any of the 26 ainote tools directly from the shell ā no Claude / Cursor / MCP host required. Useful for scripts, alfred / raycast workflows, automation, and one-off queries.
# List all tasks due today
npx @ainote/mcp call list_tasks --due_today=true
# Save a handoff (JSON form)
npx @ainote/mcp call handoff_save \
--json '{"project":"demo","topic":"poc","content":"..."}'
# Get a handoff
npx @ainote/mcp call handoff_get --project=demo --topic=poc
# Read a resource URI as JSON (load all tasks at once)
npx @ainote/mcp call list_tasks --limit=500Flag parsing: --key=value is JSON.parse-d (numbers/booleans/null/arrays/objects work directly; raw strings fall back). Pass the entire arguments object via --json '<obj>'. Add --raw for the full JSON-RPC envelope.
Auth resolution order: AINOTE_API_KEY env var ā OS keychain (from ainote-mcp login).
Onboarding MCP Tools
These tools also work inside Claude (no API key needed):
Tool | Description |
| Create account + get MCP key |
| Login + get MCP key (existing account) |
| Setup instructions |
Authentication
The CLI supports browser-based login as a more secure alternative to manually pasting API keys into your MCP config. Tokens and the MCP key are stored in the OS keychain.
Quick start
ainote-mcp login # browser-based, recommended
ainote-mcp whoami # verify current login
ainote-mcp logout # revoke + clear keychainHow it works
ainote-mcp login runs an RFC 8628 OAuth 2.0 Device Authorization Grant. The CLI generates a PKCE pair locally, opens your browser to sign in via the AI Note web app, and polls the backend until you approve. On success it stores an access token, a refresh token, and an MCP key in the OS keychain. The default MCP stdio mode automatically uses the stored MCP key ā no AINOTE_API_KEY env var needed.
Storage locations
OS | Location |
macOS | Keychain Access ā service |
Linux | libsecret (gnome-keyring / kwallet) ā service |
Windows | Credential Manager ā target |
Fallback |
|
The fallback file is only used when no system keychain is available (e.g. headless servers without libsecret).
CLI flags
--scope=mcp,read,writeā comma-separated scopes requested for the token (default:mcp,read,write)--no-browserā print the verification URL instead of auto-opening a browser (use this on SSH/CI)
Environment overrides
AINOTE_API_URLā backend URL (defaulthttps://api.ainote.dev)AINOTE_API_KEYā pre-provisioned MCP key. When set, the login flow is bypassed entirely and this key is used as-is.
Headless / CI usage
For SSH sessions, devcontainers, or CI runners that cannot open a browser, use --no-browser. The CLI will print a short user code and a verification URL; open the URL on any device (laptop, phone) signed in to your AI Note account, approve the request, then return to the terminal:
$ ainote-mcp login --no-browser
Open this URL in any browser:
https://ainote.dev/oauth/cli/device?user_code=BCDF-GHJK
Waiting for approval...
ā Logged in as you@example.comAfter login, subsequent invocations (ainote-mcp, ainote-mcp whoami) work normally with no further interaction.
Troubleshooting
Symptom | Fix |
| Run |
macOS Keychain prompt every run | Open Keychain Access, find |
Browser does not open | Re-run with |
Persistent 401 after login | Tokens were revoked server-side. Run |
| Install |
See docs/architecture/CLI_AUTH.md for the full protocol specification, sequence diagram, and security model.
Prerequisites
Node.js >= 18.0.0
npm or yarn
Claude Desktop with MCP support enabled
Installation
Option 1: Install from npm
npm install -g @ainote/mcpOption 2: Install from source
git clone https://github.com/ainote-dev/ainote-mcp.git
cd ainote-mcp-server
npm installUpdate
Update from npm (Recommended)
To update to the latest version when installed via npm:
npm update -g @ainote/mcpOr to install a specific version:
npm install -g @ainote/mcp@1.0.2Update from source
If you installed from source:
cd ainote-mcp-server
git pull origin main
npm installAfter updating, restart Claude Desktop to load the new version.
Configuration
To connect the MCP server with Claude Desktop, follow these steps.
Step 1: Get your AI Note API Key
You need an API key from your AI Note account to allow Claude to access your tasks. You can find or generate your API key in the AI Note app's settings screen.
Step 2: Configure Claude Desktop
Add the ainote-mcp server to your Claude Desktop configuration file. This file is located at:
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
Open the file and add the following JSON block inside the mcpServers object. Replace your-api-key-here with your actual AI Note API key.
{
"mcpServers": {
"ainote": {
"command": "ainote-mcp",
"env": {
"AINOTE_API_KEY": "your-api-key-here"
}
}
}
}Note: If you need to connect to a self-hosted or different AI Note server, you can add the AINOTE_API_URL environment variable as well.
"env": {
"AINOTE_API_KEY": "your-api-key-here",
"AINOTE_API_URL": "https://your-custom-api-url.com"
}Step 3: Restart Claude Desktop
After saving the configuration file, restart Claude Desktop completely. The new MCP server will be loaded, and you can start managing your AI Note tasks through Claude.
Usage
Once configured, you can interact with your AI Note tasks through Claude:
Example Conversations
You: "Show me my pending tasks"
Claude: I'll retrieve your pending tasks from AI Note...
You: "Create a new task to review the quarterly report by Friday"
Claude: I'll create that task for you with a due date set for Friday...
You: "Mark task ID 123 as completed"
Claude: I'll mark that task as completed...HTTP Endpoint
For platform integrations and services that prefer HTTP over stdio, AI Note provides a direct HTTP endpoint:
Endpoint URL
POST https://api.ainote.dev/api/mcp
Content-Type: application/jsonAuthentication
Authorization: Bearer YOUR_API_KEYRequest Format (JSON-RPC 2.0)
{
"jsonrpc": "2.0",
"method": "tools/list",
"id": 1
}Response Format
{
"jsonrpc": "2.0",
"result": {
"tools": [...]
},
"id": 1
}Supported Methods
ping- Health checkcapabilities- Server capabilitiestools/list- List available toolstools/call- Execute a specific tool
Platform Integration Examples
Kakao PlayMCP: Use the HTTP endpoint for seamless integration
Custom Applications: Build your own MCP client using the HTTP API
Enterprise Solutions: Direct server-to-server communication
This HTTP endpoint provides identical functionality to the stdio version, making AI Note MCP accessible to a broader range of platforms and integration scenarios.
4. Streaming API - For Large Data Operations
URL:
POST https://api.ainote.dev/api/mcp/streamProtocol: Server-Sent Events (SSE)
Usage: Bulk operations, large task lists, real-time progress
Best for: Applications that need to handle large datasets or show progress indicators
Streaming Methods
Method | Description |
| Stream task list with filters |
| Create single task with progress |
| Get task statistics and insights |
| Update multiple tasks with progress |
| Create up to 1000 tasks at once |
Streaming Events
event: progress
data: {"status": "starting", "total": 100}
event: data
data: {"type": "task", "data": {...}}
event: result
data: {"status": "success", "count": 100}5. Telegram Bot Integration - Via Clawdbot
Setup Guide: CLAWDBOT_SETUP.md
Tool: mcporter for MCP server bridging
Usage: Natural language task management in Telegram
# Quick setup
npm install -g mcporter
mcporter call ainote.list_tasksLocal Development Bridge (ainote-mcp-http)
Run the bundled HTTP/SSE bridge when you need a local endpoint for ChatGPT or other MCP clients that speak SSE:
ainote-mcp-httpBy default the server listens on http://localhost:3030 and exposes two endpoints:
GET /sseā establishes the SSE stream and returns thesessionIdPOST /messages?sessionId=...ā receives JSON-RPC payloads from the clientGET /healthā simple health probe for monitoring
Configuration
Environment variable | Description | Default |
| API key used for MCP key authentication | required |
| Target AI Note API base URL |
|
| Local port for the SSE server |
|
| Comma-separated list of allowed browser origins | any |
| Comma-separated list of allowed | any |
| Set to |
|
When OAuth is enabled the server expects Authorization: Bearer ... headers from the client and forwards them to the AI Note API.
Available Tools
list_tasks
List tasks from AI Note with advanced filtering options.
Basic Parameters:
status(optional): Filter by status - "pending" or "completed"limit(optional): Maximum number of tasks (default: 25, max: 500)search(optional): Search keyword in task contentis_important(optional): Filter important tasks only
Location & Category:
location(optional): Filter by location (partial match, e.g., "ģ¬ģė")category_id(optional): Filter by category UUID
Date Range Filters:
due_date_start/due_date_end: Filter by due date rangecompleted_date_start/completed_date_end: Filter by completion datecreated_date_start/created_date_end: Filter by creation date
Special Filters:
overdue(optional): Filter overdue incomplete tasksdue_today(optional): Filter tasks due todayhas_notification(optional): Filter by notification status
Sorting:
sort_by(optional): Sort field - "due_date", "created_at", "completed_at", "updated_at", "is_important"sort_order(optional): Sort direction - "asc" or "desc"
create_task
Create a new task in AI Note.
Parameters:
content(required): Task descriptionis_important(optional): Mark as important (boolean)due_date(optional): Due date in ISO formatcategory_id(optional): Category ID to assign
update_task
Update an existing task.
Parameters:
id(required): Task IDcontent(optional): New task contentis_important(optional): Update important statuscompleted_at(optional): Mark as completed (ISO format) or null to uncomplete
delete_task
Soft delete a task.
Parameters:
id(required): Task ID to delete
list_categories
List all available categories.
Parameters: None
Dev Doc Tools (v1.1.0+)
Manage AI coding tool configuration files and dev documents centrally. All docs are organized under the dev/ category hierarchy.
list_dev_docs
List dev documents with optional filtering.
Parameters:
category(optional): Subcategory filter (claude, cursor, windsurf, copilot, docs)search(optional): Search keyword in document titlecontent_type(optional): Filter by type - "markdown", "json", "yaml", "text"
get_dev_doc
Get a single dev document by title or id.
Parameters:
titleorid(one required): Document identifiercategory(optional): Subcategory to disambiguate titleinclude_versions(optional): Include version history
create_dev_doc
Create a new dev document under dev/ category.
Parameters:
title(required): Document title (e.g., "project-a-claude.md")content(required): Document contentcategory(optional): Subcategory (default: "docs")content_type(optional): Auto-detected from title extension
update_dev_doc
Update a dev document with replace, append, or prepend modes.
Parameters:
titleorid(one required): Document identifiercontent(required): New contentmode(optional): "replace" (default), "append", or "prepend"
delete_dev_doc
Soft delete a dev document.
Parameters:
titleorid(one required): Document identifier
list_dev_categories
List all subcategories under dev/ with document counts.
Parameters: None
Example: Store CLAUDE.md in ainote
You: "Save this project's CLAUDE.md content to ainote"
Claude: I'll create a dev doc in the claude category...
ā create_dev_doc(title: "myproject-claude.md", content: "...", category: "claude")
You: "Update my cursor rules in ainote"
Claude: I'll update the cursor rules doc...
ā update_dev_doc(title: "api-rules.mdc", category: "cursor", content: "...")
You: "Show me all my dev docs"
Claude: I'll list all documents under dev/...
ā list_dev_docs()Session Handoffs (cross-session / cross-device continuation)
Save a self-contained handoff note when the context window fills up or when you need to continue on another machine. Stored in the user's primary vault under handoffs/, auto-purged after 7 days.
Tool | Purpose |
| Write a handoff ( |
| Most-recent-first list, optionally filtered by project. ā ļø Triggers the 7-day stale purge as a side effect |
| Fetch by |
You: "Save a handoff for the logi-phase4 work I'm wrapping up"
Claude: ā handoff_save({project: "logi", topic: "phase4", time: "1555", content: "..."})
Stored at handoffs/logi-phase4-1555-2026-05-14.txt
(later, on the laptop):
You: "Pick up the logi-phase4 handoff"
Claude: ā handoff_get({project: "logi", topic: "phase4"})Multi-Device File Sync (sync_* / vault_sync)
sync_push / sync_pull / sync_list operate on the user's git-backed primary vault. vault_sync is the unified entrypoint that accepts an action: list|pull|push argument.
Tool | Purpose |
| Push a markdown note (path + content) into the vault repo |
| Read a markdown note from the vault by path |
| Enumerate vault paths (optionally filtered) |
| Unified wrapper around the above three |
GitHub-Backed Vaults
Tool | Purpose |
| List the user's vaults + sync status + indexed file counts |
| Create a new private vault as a GitHub repo (requires the ainote GitHub App install) |
| Return the git clone URL for an existing vault. ainote does not proxy git traffic ā use your usual GitHub credentials |
| Check whether the ainote GitHub App is installed for this user; returns an install URL otherwise |
Annotations Reference
Every tool advertises four MCP-spec annotations on tools/list so autonomous agent runtimes can reason about safety:
Hint | Meaning | Agent action |
| Tool does not mutate any server state | Safe to call without consent gates |
| Tool deletes / overwrites / purges state | Require explicit user consent or transaction boundary |
| Repeating the call with same args ends in the same state | Safe to retry on timeout / network error |
| Tool reaches an external system (GitHub, SMTP, third-party) | Outcomes may be non-deterministic; cache cautiously |
Notable annotations:
handoff_list/handoff_getare markeddestructiveHint: truebecause they run a 7-day stale-handoff purge on every call.login_and_get_keyis markedreadOnlyHint: falsebecause it creates a default MCP key when the user has none.vault_syncis conservativelydestructiveHint: truebecauseaction=pushwith empty content can delete an indexed file.
See the source-of-truth mapping at docs/todo/MCP_TOOL_ANNOTATIONS_MAPPING.md in the ainote repo.
Agent Compatibility
ainote MCP works with any client that speaks Model Context Protocol over stdio or HTTP. Tested setups:
Claude Desktop / Claude Code (stdio via this npm package)
{
"mcpServers": {
"ainote": {
"command": "npx",
"args": ["-y", "@ainote/mcp"],
"env": { "AINOTE_API_KEY": "..." }
}
}
}Claude Code (direct HTTP ā recommended for full feature set)
{
"mcpServers": {
"ainote": {
"type": "http",
"url": "https://api.ainote.dev/api/mcp",
"headers": { "Authorization": "McpKey <YOUR_MCP_KEY>" }
}
}
}The
type: "http"field is required ā without it, Claude Code's user-level MCP loader silently rejects the entiremcpServersblock.
Cursor / Windsurf (stdio)
Same as Claude Desktop config ā both editors accept the command + args + env shape.
ChatGPT / OpenAI Custom GPTs
Use the hosted HTTP endpoint via OpenAI Connectors or Custom GPT Actions. The MCP JSON-RPC body works as a regular HTTPS POST. An OpenAPI 3.1 mirror of the tool surface is planned (see docs/todo/AGENT_INTEROP_ROADMAP_2026.md Phase 1.4).
LangChain / LangGraph
Wrap the HTTP endpoint as a remote tool. Pass Authorization: McpKey <YOUR_MCP_KEY> and POST JSON-RPC requests. Tool definitions can be discovered via tools/list.
API Reference
The MCP server communicates with the AI Note API using the following endpoints:
GET /api/mcp/tasks- List tasksPOST /api/mcp/tasks- Create taskPUT /api/mcp/tasks/:id- Update taskDELETE /api/mcp/tasks/:id- Delete taskGET /api/mcp/categories- List categories
All requests require authentication via the Authorization header with your API key.
Development
Running Locally
# Clone the repository
git clone https://github.com/ainote-dev/ainote-mcp.git
cd ainote-mcp-server
# Install dependencies
npm install
# Run the server
npm startTesting with Claude Desktop
Update your Claude Desktop config to point to your local development server
Set environment variables for testing
Restart Claude Desktop
Check the MCP connection status in Claude Desktop settings
Project Structure
ainote-mcp-server/
āāā index.js # Main server implementation
āāā package.json # Package configuration
āāā README.md # English documentation
āāā README-ko.md # Korean documentation
āāā LICENSE # MIT licenseTroubleshooting
Common Issues
"API key not found" error
Ensure
AINOTE_API_KEYis set in your environment or Claude configCheck that the API key is valid and has proper permissions
"Connection refused" error
Verify the API URL is correct
Check network connectivity
Ensure the AI Note API server is running
"Tool not found" error
Restart Claude Desktop after configuration changes
Verify the MCP server is properly configured in Claude Desktop
Tasks not appearing
Check API key permissions
Verify you're querying the correct status (pending/completed)
Try using the search parameter
Debug Mode
To enable debug logging:
export DEBUG=mcp:*Contributing
We welcome contributions! Please follow these steps:
Fork the repository
Create a feature branch (
git checkout -b feature/amazing-feature)Commit your changes (
git commit -m 'Add amazing feature')Push to the branch (
git push origin feature/amazing-feature)Open a Pull Request
Development Guidelines
Follow the existing code style
Add tests for new features
Update documentation as needed
Ensure all tests pass before submitting PR
License
This project is licensed under the MIT License - see the LICENSE file for details.
Support
š§ Email: support@ainote.dev
š Issues: GitHub Issues
š¬ Discord: Join our community
Acknowledgments
Built with Model Context Protocol SDK
Powered by AI Note
Made for Claude Desktop
Available Tools
5 toolscreate_taskC
Create a new task in AI Note
| Name | Required | Description | Default |
|---|---|---|---|
| category_id | No | Category ID | |
| content | Yes | Task content | |
| due_date | No | Due date in ISO format | |
| is_important | No | Mark task as important |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool creates a task, implying a write operation, but lacks details on permissions, side effects (e.g., if it triggers notifications), error handling, or response format. This is a significant gap for a mutation tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It is front-loaded and appropriately sized, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It fails to address behavioral aspects like what happens on success or failure, and it doesn't compensate for the lack of structured data, leaving gaps in understanding how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for all parameters (e.g., 'Task content', 'Due date in ISO format'). The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for adequate but not enhanced coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new task') and the target resource ('in AI Note'), which is specific and unambiguous. It distinguishes from siblings like 'delete_task' and 'update_task' by focusing on creation. However, it doesn't explicitly contrast with 'list_tasks' or 'list_categories', keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'update_task' for modifications or 'list_tasks' for viewing. There are no prerequisites, exclusions, or context for usage, leaving the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_taskB
Delete a task (soft delete)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Task ID to delete |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It adds valuable context by specifying 'soft delete' (implying reversible/non-destructive deletion), but doesn't cover permissions needed, confirmation prompts, side effects, or what happens to associated data. The disclosure is partial but meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at just 4 words, front-loaded with the core action, and every word earns its place by adding critical information ('soft delete'). No wasted words or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is minimally adequate. It identifies the tool as a deletion operation and specifies it's 'soft', but lacks details on permissions, confirmation, return values, or error conditions that would be helpful for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter 'id' well-documented as 'Task ID to delete'. The description doesn't add parameter details beyond what the schema provides, but with only one parameter and complete schema coverage, baseline 4 is appropriate as minimal additional value is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a task'), making the purpose immediately understandable. However, it doesn't differentiate from sibling 'update_task' regarding deletion vs modification, nor does it mention what distinguishes it from potential hard-delete alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'update_task' for status changes or potential archive operations. The description mentions 'soft delete' but doesn't explain when this is appropriate versus other deletion methods or what the implications are.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesC
List all categories
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'List all categories' but doesn't disclose behavioral traits such as whether it's read-only, paginated, rate-limited, or requires authentication. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence 'List all categories', which is front-loaded and wastes no words. Every part of the sentence directly contributes to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema) and lack of annotations, the description is incomplete. It doesn't explain return values, behavioral context, or how it fits with siblings, leaving gaps in understanding for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema coverage, so no parameter documentation is needed. The description doesn't add parameter semantics, but this is acceptable given the lack of parameters, aligning with the baseline for 0 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all categories' clearly states the action (list) and resource (categories), but it's vague about scope and doesn't distinguish from sibling tools like 'list_tasks'. It's not tautological but lacks specificity about what 'all' means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_tasks' or other siblings. The description implies usage for retrieving categories but doesn't specify context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tasksC
List tasks from AI Note
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of tasks to return (default: 25, max: 500) | |
| search | No | Search keyword in task content | |
| status | No | Filter by task status |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits like pagination, rate limits, authentication needs, or what 'AI Note' entails. It misses key details for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste, clearly front-loaded with the core purpose. It's appropriately sized for a simple list tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It lacks context on return format, error handling, or the 'AI Note' system, leaving gaps for a tool with three parameters and behavioral unknowns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or default behaviors, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('tasks from AI Note'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_categories' or specify what 'AI Note' refers to, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_categories' or 'search' parameters. The description lacks context about prerequisites or typical use cases, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_taskC
Update an existing task
| Name | Required | Description | Default |
|---|---|---|---|
| completed_at | No | Mark as completed (ISO format) or null to uncomplete | |
| content | No | New task content | |
| id | Yes | Task ID | |
| is_important | No | Update important status |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Update' implies a mutation operation, it doesn't specify what permissions are required, whether changes are reversible, or what happens if the task doesn't exist. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that communicates the core purpose without any wasted words. It's appropriately sized for a simple update operation and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address what the tool returns, error conditions, or behavioral nuances. Given the complexity of an update operation and the lack of structured metadata, the description should provide more complete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are documented in the input schema. The description doesn't add any additional parameter semantics beyond what's already in the schema, so it meets the baseline expectation but doesn't provide extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and resource ('an existing task'), making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'create_task' beyond the 'existing' qualifier, which is why it doesn't reach a perfect score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'create_task' or 'delete_task'. There's no mention of prerequisites, error conditions, or specific contexts where this tool is preferred over others in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
5 tool updates
v1.0.0- First observed
create_task - First observed
delete_task - First observed
list_categories - First observed
list_tasks - First observed
update_task
TDQS
Each tool has a distinct purpose with no overlap: create_task, delete_task, update_task handle task lifecycle operations, while list_tasks and list_categories handle retrieval of different resource types. The descriptions clearly differentiate between task management and category listing, eliminating any ambiguity.
All tools follow a consistent verb_noun pattern using snake_case: create_task, delete_task, list_categories, list_tasks, update_task. The naming convention is perfectly uniform throughout the set, making it predictable and easy to understand.
With 5 tools, this server is well-scoped for a task management domain. The count is appropriate as it covers core CRUD operations for tasks (create, list, update, delete) plus category listing, without being too sparse or bloated. Each tool serves a clear purpose in the workflow.
The tool set provides complete CRUD coverage for tasks and includes category listing, covering the essential lifecycle operations. A minor gap exists in category management (e.g., create/update/delete categories), but agents can still perform core task workflows effectively with the available tools.
Maintenance
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
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yoā¦
- TaprootOAuthcom.taproothq
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
Google Keep-style notes app with an MCP server for AI agents to read/write notes.
Nifty's MCP server ā exposes tasks, projects, messages, and files as tools for AI agents.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server for Claude Desktop that provides structured memory management across chat sessions, allowing Claude to maintain context and build a knowledge base within project directories.226MIT
- AlicenseAqualityDmaintenanceA Model Context Protocol server that allows Claude Desktop to manage and execute tasks in a queue-based system, supporting planning, execution, and completion phases.102499MIT
- AlicenseAqualityFmaintenanceA Model Context Protocol server that bridges Claude with Google Tasks, allowing users to manage task lists and tasks directly through Claude interface.159748MIT
- AlicenseNot gradedqualityFmaintenanceA Model Context Protocol server that enables advanced task and project management in Todoist via Claude Desktop and other MCP-compatible clients.522MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ainote-dev/ainote-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server