Things MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools are clearly distinct by resource and action, such as add-project vs. update-project. However, some potential confusion exists: 'search' opens the search screen, while 'search-todos' performs a specific search; 'get-todos' retrieves by source, and 'get-recent-todos' gets recent ones, which might overlap in use cases. Descriptions help clarify, but minor ambiguity remains.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern throughout, with clear actions like 'add', 'get', 'update', and 'search' paired with specific nouns like 'project', 'todo', or 'areas'. All names use snake_case uniformly, making them predictable and easy to parse.
Tool Count5/5
With 15 tools, this server is well-scoped for managing tasks and projects in Things. It covers core CRUD operations for projects and to-dos, plus additional utilities like listing areas and tags, which fits the domain appropriately without being overwhelming or insufficient.
Completeness4/5
The tool set provides strong coverage for the task management domain, including creation, retrieval, and updates for projects and to-dos, plus listing areas and tags. Minor gaps exist: there's no explicit delete tool for projects or to-dos, and 'add-json' might overlap with other add tools, but agents can likely work around these with updates or existing methods.
Average 3.7/5 across 15 of 15 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the openWorldHint annotation. It mentions authentication requirements ('your Things auth-token'), which is useful since annotations don't cover authentication. However, it doesn't describe what 'Update' entails behaviorally - whether it's a partial or complete update, how conflicts are handled, or what happens to unspecified fields. With annotations providing only openWorldHint, the description could do more to explain the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with just two sentences that get straight to the point. The first sentence states the purpose, and the second provides the key requirements. There's no unnecessary verbiage, though it could be slightly more informative without sacrificing conciseness.
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 complex update tool with 18 parameters and no output schema, the description is somewhat minimal. While the schema provides excellent parameter documentation, the description doesn't explain what constitutes a successful update, what gets returned, or how to interpret the various update options. The openWorldHint annotation suggests flexibility, but the description doesn't elaborate on this behavioral aspect.
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?
With 100% schema description coverage, the input schema already documents all 18 parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it only mentions the two required parameters (authToken and id) without explaining their purpose or relationship. This meets the baseline for high schema coverage but doesn't provide additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and resource 'existing project in Things', making the purpose immediately understandable. However, it doesn't differentiate this tool from its sibling 'update-todo' tool, which appears to serve a similar update function for a different resource type.
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?
The description mentions that it 'Requires the project ID and your Things auth-token', which provides some basic prerequisites but doesn't offer guidance on when to use this tool versus alternatives like 'update-todo' or other project-related tools. No explicit when/when-not scenarios or sibling tool comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, exploratory operation. The description adds that it 'opens the search screen', suggesting a UI interaction rather than a direct data return, which provides useful behavioral context beyond the annotations.
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, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized for a simple tool and front-loads the core functionality.
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 read-only tool with good annotations and full schema coverage, the description is adequate but minimal. It lacks output information (no output schema provided) and doesn't clarify the relationship with the 'search-todos' sibling tool, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'query' fully documented in the schema. The description mentions it's 'optional search query text', which aligns with but doesn't add meaningful semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open the search screen') and target ('in Things'), specifying the resource as the search interface. However, it doesn't explicitly differentiate from the sibling 'search-todos' tool, which appears to perform a more specific search operation.
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?
The description provides minimal guidance, mentioning an optional query parameter but offering no context on when to use this tool versus alternatives like 'search-todos'. There's no mention of prerequisites, typical use cases, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include 'openWorldHint: true', indicating the tool can create new resources, which aligns with the description's 'Create a new project'. The description adds value by specifying supported fields and mentioning 'initial to-dos', but does not disclose behavioral traits like permissions needed, rate limits, or side effects (e.g., how areaId/area precedence works). No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Create a new project') and enumerates supported fields without redundancy. It avoids unnecessary words, though it could be slightly more structured (e.g., separating core vs. optional features) for optimal clarity.
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 13 parameters with full schema coverage and no output schema, the description adequately covers the tool's purpose and key inputs. However, it lacks context on usage guidelines, behavioral details (e.g., error handling), and output expectations, making it incomplete for a mutation tool with many options. Annotations provide some support but not full transparency.
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 each parameter well-documented in the schema (e.g., 'when' includes format examples). The description lists key parameters (title, notes, when/deadline, tags, area, to-dos) but does not add significant meaning beyond the schema, such as explaining interactions (e.g., areaId vs. area) or constraints. Baseline 3 is appropriate given high schema coverage.
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 specific action ('Create a new project') and resource ('in Things'), distinguishing it from sibling tools like 'add-todo' or 'update-project'. It explicitly lists the supported fields (title, notes, dates, tags, area, to-dos), making the purpose unambiguous and differentiated.
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?
The description provides no guidance on when to use this tool versus alternatives like 'add-todo' for individual tasks or 'update-project' for modifications. It lacks context about prerequisites (e.g., whether an area must exist) or exclusions (e.g., not for bulk operations), offering only a functional statement without usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which the description aligns with by using 'Get' (implying read-only). The description adds context about platform dependency ('macOS only') and implementation detail ('Uses AppleScript'), which are useful beyond annotations. However, it doesn't disclose behavioral traits like rate limits, error handling, or return format, keeping it at a baseline level.
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 two short sentences with zero waste: the first states the purpose, and the second adds essential technical constraints. It's front-loaded with the core functionality and appropriately sized for a simple tool.
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 the tool's simplicity (0 parameters, read-only, no output schema), the description covers the basic purpose and platform constraints adequately. However, it lacks details on output format (e.g., what 'projects' includes) and doesn't leverage sibling context for differentiation, making it minimally viable but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100% (though empty). With no parameters to document, the description doesn't need to compensate, and the baseline for 0 parameters is 4. The description appropriately doesn't discuss parameters, which is correct for this case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'projects from Things', making the purpose specific and understandable. However, it doesn't distinguish this tool from sibling tools like 'get-project-by-id' or 'get-areas', which would require explicit differentiation to earn a 5.
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?
The description provides no guidance on when to use this tool versus alternatives like 'get-project-by-id' or 'search'. It mentions 'Uses AppleScript (macOS only)', which is a technical constraint but not usage guidance. Without explicit when/when-not instructions or named alternatives, this scores low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which the description aligns with by using 'Get' (a read operation). The description adds value by specifying the implementation method ('Uses AppleScript') and platform constraint ('macOS only'), which aren't covered by annotations. However, it doesn't detail behavioral aspects like performance, error handling, or output format.
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 extremely concise with two short sentences that front-load the core purpose ('Get all tags from Things') and follow with implementation details. Every word earns its place, with no wasted text or unnecessary elaboration.
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 read-only tool with 0 parameters and annotations covering safety, the description is adequate but minimal. It lacks output details (no schema provided) and doesn't explain the scope of 'all tags' (e.g., if filtered or paginated). The macOS constraint is helpful, but more context on behavior would improve completeness.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, maintaining focus on the tool's purpose and constraints without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get all tags') and resource ('from Things'), making the purpose understandable. It distinguishes from some siblings like 'add-todo' or 'update-project' by focusing on retrieval, but doesn't explicitly differentiate from other get operations like 'get-areas' or 'get-projects' beyond the resource type.
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?
The description provides no guidance on when to use this tool versus alternatives. It mentions 'macOS only' as a platform constraint, but doesn't explain when to choose this over other tag-related operations (none exist in siblings) or other retrieval tools like 'get-areas' or 'get-projects' for different data types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds value by disclosing the implementation detail 'Uses AppleScript (macOS only)', which is useful context beyond annotations, but doesn't cover other behavioral aspects like error handling or output format.
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 two sentences with zero waste: the first states the core purpose, and the second adds critical implementation context. It's appropriately sized and front-loaded, making it efficient for an agent to parse.
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 the tool's low complexity (single parameter, read-only operation) and lack of output schema, the description is adequate but minimal. It covers the purpose and platform constraint, but doesn't explain what 'Get' entails (e.g., returns project details) or error cases, leaving some gaps for the agent.
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 the parameter 'id' fully documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, so it meets the baseline for high coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a specific project by its ID'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'get-projects' or 'get-todo-by-id' beyond mentioning the resource type, which keeps 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'Uses AppleScript (macOS only)', which provides platform constraints. However, it doesn't explicitly state when to use this tool versus alternatives like 'get-projects' or 'search', leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by disclosing platform dependency ('macOS only') and implementation details ('Uses AppleScript'), which aren't covered by the readOnlyHint annotation. However, it lacks information on behavioral traits such as rate limits, error handling, or what 'recently modified' entails (e.g., modification vs. creation). No contradiction with annotations is present.
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 extremely concise and front-loaded, consisting of just two sentences that efficiently convey the core functionality and key constraints. Every word earns its place, with no wasted information, making it easy to parse quickly.
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 the tool's low complexity (one optional parameter) and the presence of annotations (readOnlyHint), the description is minimally adequate. However, without an output schema, it doesn't explain return values (e.g., format of to-dos), and it lacks details on scope (e.g., all to-dos or filtered). For a read-only tool, it meets basic needs but could be more 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?
The description doesn't add any parameter-specific information beyond what's in the input schema, which has 100% coverage for the single parameter 'days'. Since the schema fully describes the parameter, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('recently modified to-dos'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get-todos' or 'search-todos', which likely have overlapping functionality, so it falls short of 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by mentioning 'macOS only' and 'recently modified', which implies when to use it (for recent items on macOS). However, it doesn't offer explicit guidance on when to choose this tool over alternatives like 'get-todos' or 'search-todos', nor does it specify exclusions or prerequisites beyond the OS requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint: true, indicating this is a safe read operation. The description adds value by disclosing the implementation method ('Uses AppleScript') and platform constraint ('macOS only'), which are behavioral traits not covered by annotations. However, it doesn't detail aspects like performance, error handling, or result format, keeping the score moderate.
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 extremely concise and front-loaded, consisting of just two sentences that efficiently convey the core functionality and key constraints. Every word earns its place without redundancy, making it easy for an AI agent to parse quickly.
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 search tool with one parameter and read-only annotations, the description covers basic purpose and platform limits. However, without an output schema, it doesn't explain return values (e.g., result format or pagination), and it lacks details on search behavior (e.g., case sensitivity, partial matches). Given the simplicity, it's adequate but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the 'query' parameter fully documented. The description adds minimal semantics by mentioning that the search matches against 'titles and notes,' but this is largely redundant with the schema's description. Given the high schema coverage, a baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for to-dos by title or notes content.' It specifies the verb (search) and resource (to-dos), and mentions the search scope (title or notes). However, it doesn't explicitly distinguish this tool from sibling tools like 'search' or 'get-todos', which might offer similar functionality, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage context by stating 'Uses AppleScript (macOS only),' which implies platform restrictions. However, it doesn't offer explicit guidance on when to use this tool versus alternatives like 'search' or 'get-todos' from the sibling list, nor does it specify prerequisites or exclusions beyond the macOS note. This leaves room for ambiguity in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, indicating a safe read operation. The description adds value by specifying the implementation method ('Uses AppleScript') and platform constraint ('macOS only'), which aren't covered by annotations. However, it lacks details on return format, error handling, or other behavioral traits, so it only partially compensates for the absence of richer annotations.
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 extremely concise with two sentences: one stating the purpose and one adding implementation context. Every word earns its place, and it's front-loaded with the core functionality, making it efficient and well-structured.
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 the tool's simplicity (0 parameters, read-only operation) and lack of output schema, the description is adequate but could be more complete. It covers purpose and platform constraints but doesn't explain what 'areas' are in the Things context or what the return data looks like, leaving some gaps for an AI agent to infer.
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?
With 0 parameters and 100% schema description coverage, the schema fully documents the input (none required). The description doesn't need to add parameter details, so it meets the baseline for this scenario. No additional semantic information is provided or needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get all areas') and resource ('from Things'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'get-projects' or 'get-todos' beyond specifying the resource type, which is why it doesn't reach 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context with 'Uses AppleScript (macOS only)', suggesting platform restrictions, but doesn't explicitly state when to use this tool versus alternatives like 'get-projects' or 'get-todos'. No guidance on prerequisites or exclusions is provided, leaving usage somewhat ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include 'openWorldHint: true', which suggests flexibility, but the description adds useful behavioral context: it discloses that the tool supports both creation and updates, requires an auth-token for updates, and handles nested structures. However, it doesn't mention potential side effects, error handling, or rate limits, leaving some behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. Sentences are efficient, but the last sentence could be more concise by combining update instructions. Overall, it avoids redundancy and each sentence adds value, though minor improvements in flow are possible.
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 the tool's complexity (handling creation and updates of nested structures) and lack of output schema, the description is moderately complete. It covers key usage aspects but doesn't explain return values or error cases. With annotations providing some context and schema covering parameters, it meets basic needs but could benefit from more detail on outcomes.
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 fully documents parameters. The description adds minimal semantics beyond the schema: it reiterates that 'data' should be an array with 'type' and 'attributes', and notes auth-token is required for updates. This provides slight clarification but doesn't significantly enhance understanding beyond the schema's detailed 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 the tool's purpose: 'Create complex projects and to-dos using the Things JSON command. Supports nested projects with headings, checklist items, and to-dos.' It specifies the verb ('create'), resource ('projects and to-dos'), and distinguishes from siblings like 'add-project' or 'add-todo' by emphasizing JSON-based creation with complex nested structures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: 'For updates, include "operation": "update" and "id" fields, and provide auth-token.' This indicates when to use this tool for updates versus creation, though it doesn't explicitly name alternatives like 'update-project' or 'update-todo' for updates, nor does it specify when to use this over simpler sibling tools like 'add-project' for basic operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide openWorldHint=true, indicating flexible input handling. The description adds valuable context beyond this: it discloses the tool 'Uses the Things URL scheme' (implementation detail affecting behavior) and lists specific supported fields, giving practical insight into what can be set. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose ('Create a new to-do in Things'), followed by a concise list of supported fields and a key implementation note. It avoids redundancy, though the list of fields is somewhat lengthy but necessary for clarity.
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 complexity (17 parameters, no output schema) and rich schema coverage, the description is reasonably complete. It covers purpose, supported fields, and a behavioral note. However, it lacks details on error handling, response format, or interactions with sibling tools, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter well-documented in the schema (e.g., format for 'when', max lengths). The description adds no additional parameter semantics beyond listing field names, so it meets the baseline of 3 where the schema does the heavy lifting.
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 explicitly states 'Create a new to-do in Things' with a specific verb ('Create') and resource ('to-do'), clearly distinguishing it from sibling tools like 'update-todo' (modifies existing) or 'get-todos' (reads). It lists supported fields (title, notes, dates, tags, etc.) to further clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating to-dos but doesn't explicitly state when to use this vs. alternatives like 'add-json' (for batch creation) or 'update-todo' (for modifications). No guidance on prerequisites (e.g., needing Things app) or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide openWorldHint: true, indicating flexibility in parameter usage. The description adds value by listing the specific fields that can be updated (title, notes, dates, tags, etc.), which goes beyond the annotations. However, it does not disclose behavioral traits like rate limits, error handling, or what happens when only some fields are provided, leaving room for improvement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and requirements, followed by a concise list of updatable fields. It avoids redundancy and uses efficient phrasing, though the list of fields could be slightly more structured (e.g., grouped by category) for optimal readability.
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 complexity of 23 parameters and no output schema, the description adequately covers the tool's purpose and scope. It lists the updatable fields, which helps contextualize the many parameters. However, it lacks details on return values or error cases, which would be beneficial for a mutation tool with no output 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 description coverage is 100%, so the schema already documents all 23 parameters thoroughly. The description adds minimal value by summarizing the updatable fields but does not provide additional syntax, format details, or usage nuances beyond what the schema specifies. This meets the baseline for high schema coverage.
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 'update' and resource 'existing to-do in Things', distinguishing it from sibling tools like 'add-todo' (creation) and 'update-project' (different resource). It specifies the exact operation with the required parameters, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Requires the to-do ID and your Things auth-token', providing clear prerequisites. However, it does not specify when to use this tool versus alternatives like 'update-project' or 'add-todo', nor does it mention any exclusions or specific scenarios where this tool is preferred over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds useful context about platform dependency ('macOS only') and implementation method ('Uses AppleScript'), which aren't covered by annotations. However, it doesn't describe error handling, return format, or performance characteristics.
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 extremely concise (two short sentences) with zero wasted words. The first sentence states the core purpose, and the second adds essential implementation context. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with good annotations (readOnlyHint) and full schema coverage, the description provides adequate context about platform constraints and implementation. The main gap is the lack of output schema, but the description doesn't need to explain return values since it's a straightforward get-by-id operation.
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 the single parameter 'id' fully documented as 'The ID of the to-do to retrieve'. The description doesn't add any additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get a specific to-do') and resource ('by its ID'), distinguishing it from sibling tools like 'get-todos' (list) and 'get-recent-todos' (filtered list). The phrase 'Uses AppleScript (macOS only)' further clarifies implementation constraints.
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 implies usage context by specifying 'by its ID' and 'macOS only', which helps differentiate from tools like 'search-todos' or 'get-recent-todos'. However, it doesn't explicitly state when to use this versus alternatives like 'get-todo-by-id' versus 'get-todos' for bulk retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true and openWorldHint=true, indicating safe, read-only operations with flexible inputs. The description adds context by specifying the navigation aspect (implying UI interaction) and listing built-in list IDs, but does not disclose further behavioral traits like rate limits, authentication needs, or what 'show' entails beyond navigation. With annotations covering safety, a 3 is appropriate as the description adds some value but not rich behavioral details.
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 appropriately sized with two sentences: the first states the purpose and scope, and the second lists built-in list IDs for clarity. Every sentence earns its place by providing essential information without redundancy, making it 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 moderate complexity (navigation with three parameters), rich annotations (readOnlyHint, openWorldHint), and 100% schema coverage, the description is mostly complete. It covers what the tool does and provides examples, but lacks details on output (no output schema) or explicit usage boundaries. For a read-only navigation tool, this is sufficient but not exhaustive.
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 clear descriptions for 'id', 'query', and 'filter' parameters. The description adds minimal value by listing built-in list IDs (which are already in the schema for 'id'), but does not explain parameter interactions (e.g., 'id' overrides 'query') or provide additional semantics beyond the schema. Baseline 3 is correct when schema does the heavy lifting.
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 specific action ('Navigate to and show') and the resources involved ('a list, project, area, tag, or to-do in Things'), distinguishing it from siblings like 'get-areas' or 'search' which retrieve data rather than navigate. It also lists built-in list IDs, providing concrete examples of what can be shown.
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 implies usage by specifying what items can be shown (lists, projects, areas, tags, to-dos) and listing built-in list IDs, giving clear context for when to use it. However, it does not explicitly state when not to use it or name alternatives (e.g., 'get-todos' for retrieving data without navigation), which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description doesn't contradict this. It adds valuable context beyond annotations: the 'Uses AppleScript (macOS only)' disclosure about implementation and platform dependency, which isn't captured in annotations. However, it lacks details on rate limits, auth needs, or return format.
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 two sentences, front-loaded with the core purpose, followed by critical constraints. Every word earns its place: no fluff, clear and efficient structure.
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 moderate complexity (4 parameters, no output schema), the description is fairly complete. It covers purpose, usage rules, and platform constraints. However, without output schema, it doesn't describe return values or pagination, leaving a minor gap for a retrieval 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%, with each parameter well-documented in the schema (e.g., 'list' includes enum-like values). The description adds minimal semantics by mentioning the source types but doesn't provide extra syntax or format details beyond the schema. Baseline 3 is appropriate given high schema coverage.
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 resource ('to-dos from Things'), specifies the filtering options ('by list, project, area, or tag'), and distinguishes from siblings like 'get-recent-todos' or 'search-todos' by emphasizing exact source specification. It's specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Specify exactly one source', providing clear usage rules. It implies when not to use alternatives by focusing on filtered retrieval rather than search or recent items, and the platform constraint ('macOS only') adds context for exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![things-app-mcp MCP server](https://glama.ai/mcp/servers/lucas-flatwhite/things-app-mcp/badges/card.svg)](https://glama.ai/mcp/servers/lucas-flatwhite/things-app-mcp)

Score Badge

Copy to your README.md:

[![things-app-mcp MCP server](https://glama.ai/mcp/servers/lucas-flatwhite/things-app-mcp/badges/score.svg)](https://glama.ai/mcp/servers/lucas-flatwhite/things-app-mcp)

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/lucas-flatwhite/things-app-mcp'

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