Integrates with Things.app task manager for macOS, allowing creation, viewing, updating, and organization of tasks, projects, areas, and tags.
Required platform for running the MCP server as it integrates with Things.app, which is only available on macOS.
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., "@Things MCP Server create a task to review the quarterly report and schedule it for 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.
Control your Things.app tasks directly from Claude Code, Claude Desktop, Cursor, and other AI assistants using the Model Context Protocol (MCP).
This MCP server lets AI assistants interact with your Things.app tasks on macOS. You can:
Create new tasks and projects
Update existing items
View your task database with detailed summaries
Schedule tasks for specific dates
Organize with areas, tags, and deadlines
Related MCP server: Things Cloud MCP
For updating existing tasks, you need an authorization token:
Open Things.app on macOS
Go to Things → Preferences → General
Check "Enable Things URLs"
Copy the authorization token that appears
Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
{
"mcpServers": {
"things": {
"command": "npx",
"args": ["@wenbopan/things-mcp"],
"env": {
"THINGS_AUTH_TOKEN": "your-token-here"
}
}
}
}Create .cursor/mcp.json in your project or ~/.cursor/mcp.json globally:
{
"things": {
"command": "npx",
"args": ["@wenbopan/things-mcp"],
"env": {
"THINGS_AUTH_TOKEN": "your-token-here"
}
}
}After configuration, restart your AI assistant to load the MCP server.
"Show me my today's tasks and create a project for the new marketing campaign with initial tasks for research, design, and content creation."
"Update the mobile app project to add design review and testing tasks, then schedule the design review for next Monday."
"Move all my unscheduled shopping tasks to the 'Personal' area and tag them with 'weekend'."
"Give me a summary of all active projects with their deadlines and completion status."
"Create a task to call the dentist, schedule it for tomorrow, and set a deadline for end of week."
MIT
Issues and pull requests welcome! Please ensure all tests pass before submitting.
Create a new project in Things.app. Add notes, tags, assign to areas, and pre-populate with initial to-dos.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Project title (required). Clear name describing the project goal, outcome, or deliverable | |
| notes | No | Project description, objectives, scope, or additional context (max 10,000 characters). Supports markdown formatting for rich text documentation | |
| when | No | Schedule when to start working on this project. Use "today" to start immediately, "tomorrow" to start next day, "evening" to start later today, "anytime" for flexible timing, "someday" for future consideration, or ISO date format (YYYY-MM-DD) for specific start date | |
| deadline | No | Set a deadline for project completion in ISO date format (YYYY-MM-DD). Creates deadline tracking and reminders in Things.app | |
| tags | No | Array of tag names for categorizing and organizing the project (max 20 tags). Tags help with filtering and project management | |
| areaId | No | ID of the area of responsibility to assign this project to. Use this when you know the specific area ID | |
| areaName | No | Name of the area of responsibility to assign this project to (e.g., "Work", "Personal", "Health", "Finance"). Areas help organize projects by life domain | |
| initialTodos | No | Array of initial to-do item descriptions to create within the project (max 50 items). Each string becomes a separate task within the project | |
| completed | No | Mark the project as completed immediately upon creation (default: false). Useful for logging already completed projects | |
| canceled | No | Mark the project as canceled immediately upon creation (default: false). Useful for recording projects that are no longer viable | |
| creationDate | No | Override the creation date with a specific ISO8601 datetime (YYYY-MM-DDTHH:MM:SS). Useful for importing historical project data | |
| completionDate | No | Set a specific completion date using ISO8601 datetime (YYYY-MM-DDTHH:MM:SS). Only used when completed is true |
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 describes the creation behavior and supported fields but omits details on error handling, return value, idempotency, or permissions.
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 two sentences, front-loaded with the core action, and no extraneous words. It efficiently conveys the purpose and key features.
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 12 parameters fully described in the schema and no output schema, the description is adequate but incomplete. It does not mention what the tool returns (e.g., project ID) or handle error conditions, which are important 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?
Schema coverage is 100% with detailed parameter descriptions in the input schema. The tool description only provides a high-level summary of capabilities (notes, tags, areas, todos) without adding meaning beyond what the schema already provides.
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 project') and the resource ('in Things.app'), and lists specific capabilities (notes, tags, areas, initial to-dos) that distinguish it from sibling tools like add_todo.
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 implies usage for project creation but does not explicitly state when to use this tool versus alternatives like add_todo or update_project. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new to-do item in Things.app. Add notes, tags, checklist items, and assign to projects or areas.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | To-do title (required). Clear, actionable description of the task | |
| notes | No | Additional notes or details for the to-do (max 10,000 characters). Supports markdown formatting for rich text | |
| when | No | Schedule the to-do for a specific time. Use "today" for immediate action, "tomorrow" for next day, "evening" for later today, "anytime" for no specific time, "someday" for future consideration, or ISO date format (YYYY-MM-DD) for specific date | |
| deadline | No | Set a deadline for the to-do in ISO date format (YYYY-MM-DD). Creates a deadline reminder in Things.app | |
| tags | No | Array of tag names for organizing and categorizing the to-do (max 20 tags). Tags help with filtering and organization | |
| checklistItems | No | Array of checklist item descriptions to add as sub-tasks (max 100 items). Each item becomes a checkable sub-task within the to-do | |
| projectId | No | ID of the project to add this to-do to. Use this when you know the specific project ID | |
| projectName | No | Name of the project to add this to-do to. Things.app will find the project by name and add the to-do there | |
| areaId | No | ID of the area of responsibility to assign this to-do to. Use this when you know the specific area ID | |
| areaName | No | Name of the area of responsibility to assign this to-do to (e.g., "Work", "Personal", "Health") | |
| headingId | No | ID of a specific heading within the target project to organize the to-do under | |
| headingName | No | Name of a heading within the target project to organize the to-do under (e.g., "Phase 1", "Research") | |
| completed | No | Mark the to-do as completed immediately upon creation (default: false). Useful for logging already completed tasks | |
| canceled | No | Mark the to-do as canceled immediately upon creation (default: false). Useful for recording tasks that are no longer needed | |
| creationDate | No | Override the creation date with a specific ISO8601 datetime (YYYY-MM-DDTHH:MM:SS). Useful for importing historical data | |
| completionDate | No | Set a specific completion date using ISO8601 datetime (YYYY-MM-DDTHH:MM:SS). Only used when completed is true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavioral traits. It mentions creating a to-do but does not address side effects, required permissions, rate limits, or what happens on failure. The lack of annotations places full burden on description, which is insufficient.
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 two short, front-loaded sentences with no fluff. Every part adds value.
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?
With 16 parameters and no output schema, the description should cover return values and error cases. It only lists features without explaining what is returned (e.g., created to-do ID) or potential errors.
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 detailed parameter descriptions. The tool description adds minimal extra meaning beyond summarizing the parameter types. Baseline of 3 is appropriate.
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 it creates a new to-do item in Things.app and lists key features (notes, tags, checklists, project/area assignment). This distinguishes it from sibling tools like update_todo or add_project.
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 on when to use this tool versus alternatives such as update_todo or add_project. The description simply says what it does without context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export complete Things database as structured JSON for debugging, backup, or data processing.
| Name | Required | Description | Default |
|---|---|---|---|
| includeCompleted | No | Include completed/canceled tasks and projects in the export (default: false) | |
| includeTrash | No | Include trashed items in the export (default: false). Use with caution as this includes deleted data | |
| minimal | No | Export minimal data structure with only essential fields (default: false). Reduces output size for processing | |
| prettify | No | Pretty-print JSON with indentation (default: true). Set to false for compact single-line output |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It describes an export operation, which is implicitly read-only, but does not explicitly confirm no data modification, rate limits, or authentication needs. The description adds minimal behavioral context beyond the tool name.
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, front-loaded sentence of 14 words with no filler. It efficiently conveys the action, resource, format, and use cases.
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 output schema, the description lacks detail on the exact structure of the JSON output. It mentions 'structured JSON' but does not specify fields or if the export is full or incremental. For a tool with 4 optional parameters, more context on behavior could be useful.
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?
Input schema coverage is 100%, so parameters are well-documented in the schema. The description does not add any additional meaning or context for the parameters beyond what the schema already provides.
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 verb 'Export', the resource 'complete Things database', and the format 'structured JSON'. It also lists use cases (debugging, backup, data processing), distinguishing it from sibling tools that create or update individual items.
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 gives implied usage (for debugging, backup, data processing) but does not explicitly state when NOT to use this tool or how it compares to siblings like things_summary. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a summary of your Things database with filtering options. Returns formatted Markdown or structured JSON data for tasks, projects, areas, and tags.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Output format for the summary. Use "markdown" for readable formatted summary (default) or "json" for structured data that can be processed by other tools | markdown |
| includeCompleted | No | Include completed tasks and projects in the summary (default: false). When true, shows recently completed items for reference | |
| areas | No | Filter to show only specific areas by name (e.g., ["Work", "Personal"]). If not provided, shows all areas | |
| tags | No | Filter to show only tasks/projects with specific tags (e.g., ["urgent", "review"]). If not provided, shows all items | |
| projects | No | Filter to show only specific projects by name. If not provided, shows all projects |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions filtering and output formats but does not disclose whether the tool is read-only, if it modifies data, or any authorization needs. Basic safety is implied by the verb 'Generate' but not explicit.
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 sentence that covers purpose and key capabilities efficiently. However, it lacks structural elements like bullet points or separation of concerns.
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 output schema and no annotations, the description is somewhat sparse. It mentions tasks, projects, areas, and tags but does not explain the summary's structure or depth. Adequate for basic understanding but not fully complete.
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 detailed parameter docs. The description adds no new meaning beyond the schema, so baseline 3 is appropriate.
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 verb 'Generate', the resource 'summary of your Things database', and mentions filtering options and output formats. It distinguishes well from sibling CRUD tools like add_project and update_todo.
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 implies usage for generating summaries but does not explicitly state when to use this tool versus alternatives like export_json. No when-not or comparative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing project in Things.app. Modify title, notes, scheduling, tags, area assignment, and completion status.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The unique ID of the project to update. This ID can be obtained from the list_projects tool | |
| title | No | Update the project title with a new clear name describing the project goal, outcome, or deliverable | |
| notes | No | Replace existing notes with new project description, objectives, or context (max 10,000 characters). Supports markdown formatting. This completely replaces existing notes | |
| prependNotes | No | Add text to the beginning of existing notes without replacing them. Useful for adding project updates or new objectives | |
| appendNotes | No | Add text to the end of existing notes without replacing them. Useful for adding progress updates or new requirements | |
| when | No | Reschedule when to start working on this project. Use "today" to start immediately, "tomorrow" to start next day, "evening" to start later today, "anytime" for flexible timing, "someday" for future consideration, or ISO date format (YYYY-MM-DD) for specific start date | |
| deadline | No | Update the project deadline in ISO date format (YYYY-MM-DD). Creates or updates deadline tracking and reminders in Things.app | |
| tags | No | Replace all current tags with this new set of tag names (max 20 tags). This completely replaces existing tags for the project | |
| addTags | No | Add these tag names to existing tags without removing current ones (max 20 total tags). Preserves existing project tags | |
| areaId | No | Move the project to a different area of responsibility by specifying the area ID | |
| areaName | No | Move the project to a different area of responsibility by specifying the area name (e.g., "Work", "Personal", "Health", "Finance") | |
| completed | No | Mark the project as completed (true) or reopen it (false). Completed projects are moved to the Logbook along with all their to-dos | |
| canceled | No | Mark the project as canceled (true) or restore it (false). Canceled projects are moved to the Trash along with all their to-dos | |
| creationDate | No | Override the creation date with a specific ISO8601 datetime (YYYY-MM-DDTHH:MM:SS). Useful for data migration or historical project tracking | |
| completionDate | No | Set a specific completion date using ISO8601 datetime (YYYY-MM-DDTHH:MM:SS). Only used when marking the project as completed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description reveals important behaviors: notes and tags replacement vs. append, completed/canceled moving to Logbook/Trash. Could add more on idempotency or error cases.
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?
Two sentences, front-loaded with verb and resource. Efficient and to the point, though slightly more structure (e.g., listing categories) could help. No wasted words.
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 15-parameter tool, description covers all categories of updates. Lacks return value info, but given no output schema and complexity, still quite complete.
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 coverage is 100%, so description adds limited extra meaning beyond schema. It mentions markdown support for notes and reminders for deadline, but these are minor. Baseline 3 is appropriate.
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?
Clearly states 'Update an existing project in Things.app' with specific verb and resource, and lists modifiable aspects. Distinguishes from sibling tools like add_project (create) and update_todo.
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?
Implied usage via 'update an existing project', but no explicit when-to-use or when-not-to-use statements. Lacks mention of alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing to-do item in Things.app. Modify title, notes, scheduling, tags, checklist items, project/area assignment, and completion status.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The unique ID of the to-do to update. This ID can be obtained from the list_todos tool | |
| title | No | Update the to-do title with a new clear, actionable description of the task | |
| notes | No | Replace existing notes with new content (max 10,000 characters). Supports markdown formatting. This completely replaces existing notes | |
| prependNotes | No | Add text to the beginning of existing notes without replacing them. Useful for adding updates or new information | |
| appendNotes | No | Add text to the end of existing notes without replacing them. Useful for adding follow-up information or status updates | |
| when | No | Reschedule the to-do. Use "today" for immediate action, "tomorrow" for next day, "evening" for later today, "anytime" for no specific time, "someday" for future consideration, or ISO date format (YYYY-MM-DD) for specific date | |
| deadline | No | Update the deadline in ISO date format (YYYY-MM-DD). Creates or updates deadline reminder in Things.app | |
| tags | No | Replace all current tags with this new set of tag names (max 20 tags). This completely replaces existing tags | |
| addTags | No | Add these tag names to existing tags without removing current ones (max 20 total tags). Preserves existing tags | |
| checklistItems | No | Replace all current checklist items with this new set (max 100 items). This completely replaces existing checklist items | |
| prependChecklistItems | No | Add these checklist items to the beginning of the existing checklist without removing current items | |
| appendChecklistItems | No | Add these checklist items to the end of the existing checklist without removing current items | |
| projectId | No | Move the to-do to a different project by specifying the project ID | |
| projectName | No | Move the to-do to a different project by specifying the project name. Things.app will find the project by name | |
| areaId | No | Move the to-do to a different area by specifying the area ID | |
| areaName | No | Move the to-do to a different area by specifying the area name (e.g., "Work", "Personal", "Health") | |
| headingId | No | Move the to-do under a specific heading within the target project by heading ID | |
| headingName | No | Move the to-do under a specific heading within the target project by heading name (e.g., "Phase 1", "Research") | |
| completed | No | Mark the to-do as completed (true) or reopen it (false). Completed to-dos are moved to the Logbook | |
| canceled | No | Mark the to-do as canceled (true) or restore it (false). Canceled to-dos are moved to the Trash | |
| creationDate | No | Override the creation date with a specific ISO8601 datetime (YYYY-MM-DDTHH:MM:SS). Useful for data migration | |
| completionDate | No | Set a specific completion date using ISO8601 datetime (YYYY-MM-DDTHH:MM:SS). Only used when marking as completed |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'Update' and lists fields, omitting side effects (e.g., replacement vs. append behaviors, authorization needs, or data persistence). The schema descriptions cover specifics but the tool description itself lacks 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence efficiently conveying the tool's purpose. It is concise but could benefit from more structure (e.g., bullet points) for readability.
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 high parameter count (22), no output schema, and no annotations, the description is insufficiently complete. It lacks information about return values, error handling, or important behavioral nuances (e.g., idempotency, constraints).
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 input schema has 100% description coverage, so the schema already documents each parameter in detail. The tool description adds only a high-level list of categories, providing marginal value beyond the schema.
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 verb 'Update' and the resource 'existing to-do item in Things.app', listing modifiable fields. However, it does not differentiate from sibling tools like add_todo or update_project, which have overlapping scopes.
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 implies use when modifying an existing to-do, but provides no explicit guidance on when not to use it or alternatives like add_todo for new items or update_project for project-level changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
add_projectadd_todoexport_jsonthings_summaryupdate_projectupdate_todoEach tool has a clear and distinct purpose: adding projects/todos, updating them, exporting data, and generating summaries. There is no overlap or ambiguity between these actions.
All tools follow a consistent verb_noun pattern using snake_case (e.g., add_project, update_todo, export_json). The naming is predictable and uniform across the entire set.
With 6 tools, the server is well-scoped for a personal task management system. It covers core CRUD (without delete) for projects and todos, plus export and summary utilities—each tool earns its place.
The tool set covers creation, retrieval (via summary and export), and update for projects and todos, but missing delete operations for both. Additionally, there are no dedicated tools for managing areas or tags independently, which limits lifecycle coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Official Todoist MCP server for AI assistants to manage tasks, projects, and workflows.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wbopan/things-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
