reminders-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource+action: list management, reminder management, status check, and viewing. No two tools have overlapping purposes, as show-reminders is for reminders while list-lists is for lists, and edit-reminder vs complete-reminders serves singular vs bulk completion.
Naming Consistency4/5
Most tools follow a consistent verb-noun hyphenated pattern (show-reminders, create-list, add-reminder, etc.), but 'status' is a single noun that does not fit the verb-noun convention. This is a minor deviation in an otherwise predictable naming scheme.
Tool Count5/5
With 10 tools, the server is well-scoped for a reminders domain, covering both list and reminder operations without bloat. Each tool earns its place, and the count is within the ideal range for maintainability.
Completeness5/5
The tool set provides full lifecycle coverage: lists can be created, renamed, listed, and deleted; reminders can be added, shown, edited, completed, and deleted. The addition of a status check for authorization fills a practical need, leaving no obvious gaps.
Average 3.9/5 across 10 of 10 tools scored. Lowest: 3.3/5.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states the action without mentioning side effects, what happens if a list with the same name already exists, permissions required, or the return value. This lack of detail leaves the agent without important behavioral context, though the description is not misleading.
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, concise sentence that front-loads the verb and object. Every word earns its place, and there is no redundancy or filler. It is appropriately sized for the tool's simplicity.
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?
The tool has only one parameter and no output schema, so the description is mostly adequate. However, it does not address edge cases like duplicate list names, naming constraints, or what happens on success/failure. Given the low complexity, this is a moderate gap, making the description minimally viable but not 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 input schema fully describes the 'name' parameter with a clear description: 'Name of the list to create.' The description's phrase 'with the given name' adds no new meaning beyond what the schema already provides. Since schema coverage is 100%, the baseline is 3, and the description does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a new reminder list with the given name.' It uses the specific verb 'create' and names the resource 'reminder list', distinguishing it from siblings like 'rename-list' and 'delete-list'. This is a clear and unambiguous purpose statement.
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, such as 'list-lists' to check existing lists or 'rename-list' to modify one. There are no prerequisites, exclusions, or context about when creation is appropriate. The agent must infer usage solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action and does not disclose behaviors such as error conditions (e.g., list not found, duplicate newName), side effects, or whether the operation is reversible. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's purpose without redundancy or unnecessary detail.
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?
The tool is simple with only two well-documented parameters and no output schema. However, the lack of annotations and absence of any information about return values, error handling, or preconditions leaves some gaps. It is adequate for basic invocation but not fully complete for an agent needing robust behavioral context.
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?
Input schema coverage is 100% with descriptive parameter names and brief descriptions ('Current name of the list', 'New name for the list'). The description adds no additional parameter context, so a baseline of 3 is appropriate as the schema carries the semantic weight.
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 uses a specific verb 'Rename' with a clear resource 'existing reminder list'. It distinguishes itself from sibling tools like create-list and delete-list by specifying the action is a rename on an existing entity.
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 when to use the tool (when renaming an existing reminder list) but does not explicitly contrast with alternatives or state exclusions. The word 'existing' provides some context, but no direct comparison to sibling tools is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of disclosing behavior. It only states 'Create a new reminder' and lists supported attributes, but does not mention success/failure behavior, permissions, default list handling, or what happens if a specified list does not exist. The description is minimal and lacks depth.
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 concise sentences: the first identifies the action, the second summarizes capabilities. Every word is useful, and there is no redundancy or irrelevant detail.
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?
The tool has no output schema and no annotations, yet the description is only a basic overview. It does not clarify return values, default list behavior, error cases, or the interaction with sibling tools (e.g., whether the list must pre-exist). It is adequate for a simple create operation but leaves several 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%, so the schema already documents all five parameters. The description's phrase 'list, due date, notes, and priority' merely echoes the schema without adding extra meaning or usage nuances.
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 reminder in Apple Reminders,' using a specific verb and resource, and lists supported fields (list, due date, notes, priority). This clearly distinguishes it from sibling tools like edit-reminder, complete-reminders, and delete-reminders.
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 clearly indicates the tool is for creating new reminders, which sets it apart from siblings for editing, completing, or deleting reminders. However, it does not explicitly mention alternatives or state when not to use this tool.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the input interpretation (indexes or UUID prefixes) but does not mention what happens after completion, idempotency, or error handling. For a simple mutation tool, this is adequate but leaves some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and includes essential reference information without any wasted words. It earns a high score for efficiency and 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?
For a simple tool with one parameter and no output schema, the description covers the core usage: what the tool does and how to specify inputs. It doesn't elaborate on return values or error cases, but given the low complexity, this is nearly complete. A minor gap is the lack of mention of what constitutes 'completed' status, but this is not critical.
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 schema already documents the 'ids' parameter with a description that mirrors the tool description ('Reminder index numbers or ID/UUID prefixes to mark complete'). Since schema coverage is 100%, the description adds little beyond what the schema provides, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Mark one or more reminders as completed') with a specific verb and resource. It also distinguishes from siblings by focusing on the 'complete' operation, distinct from add/edit/delete. The reference method (index numbers or ID/UUID prefixes) adds further specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical usage guidance by explaining how to reference reminders ('from show output' or ID/UUID prefixes), which implies a prerequisite workflow. It does not explicitly contrast with alternatives like delete-reminders, but the context is clear enough for an agent to choose this tool for completing tasks.
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?
No annotations are present, so the description carries the burden of behavioral disclosure. It explains the reference method and lists modifiable fields, but does not state whether unspecified fields remain unchanged, what happens on invalid references, or whether the operation is a partial update. 'Modify' implies a write operation, so basic behavior is clear, but deeper semantics are missing.
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 action, and contains no filler. It efficiently covers the purpose, reference method, and modifiable fields without unnecessary detail.
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?
Despite having 9 parameters and no output schema, the description adequately captures the tool's scope and usage. It does not explicitly mention every parameter (e.g., 'clearDue', 'incomplete'), but the schema covers them. The description provides enough behavioral context for moderate complexity, though it could be more explicit about the update semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter having a description, so baseline is 3. The description adds a small hint for the 'id' parameter ('from show output') not present in the schema, but otherwise repeats what the schema already covers. The added value is minimal.
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 opens with 'Modify an existing reminder', which clearly states the verb and resource. It distinguishes from siblings like 'add-reminder' and 'delete-reminder' by focusing on modification. The reference method ('index number or ID/UUID prefix') adds specificity beyond the general purpose.
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 on what can be changed ('title, list, due date, notes, priority, or completion status') and how to reference the reminder. It does not explicitly compare to alternatives like 'complete-reminders', but the scope is implicitly clear, so no exclusion guidance is given.
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?
With no annotations provided, the description carries the full burden. It does imply a read-only operation with 'View', and it enumerates supported filter values, which provides behavioral context. However, it does not explicitly state the absence of side effects, authentication needs, or how results are returned, so it's minimally adequate but not rich.
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, and every word contributes. It efficiently lists the supported filter values and the optional list filter without redundancy, making it appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two optional parameters and no output schema, the description covers the core usage: viewing reminders with various filters. It does not mention default behavior (though the schema does) or output format, but these are minor gaps for a read-only listing tool, so it's fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'filter' and 'list' having explicit descriptions. The tool description adds only a brief echo ('Optionally filter by list name') and does not elaborate on parameter semantics beyond what the schema already provides, so it meets the baseline but adds little extra value.
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 ('View') and resource ('reminders'), and enumerates specific filter options (today, tomorrow, week, etc.). This distinguishes 'show-reminders' from sibling tools like 'add-reminder', 'delete-reminders', or 'complete-reminders', which imply different actions.
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 gives clear context on what filters are available (time range or status) and that list name is an optional filter. However, it does not explicitly state when to prefer this tool over siblings or mention any exclusions, so it falls just short of explicit when/when-not guidance.
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?
With no annotations provided, the description must fully disclose behavior. It states the tool 'checks' and returns a boolean-like result, implying a read-only operation with no side effects. However, it does not explicitly state that it is safe to call repeatedly or that it does not modify data, leaving some room for inference.
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, focused sentence that states the action, the resource, and the return value. It is front-loaded with the most important information and contains no filler or redundancy, making it highly concise and well-structured.
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 status-checking tool with no parameters and no output schema, the description adequately conveys what it does and what it returns. It could specify the exact return format (e.g., boolean) for full completeness, but the qualitative description is sufficient given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%, meaning there is nothing for the description to add beyond what the schema already conveys. The baseline for zero-parameter tools is 4, and the description does not need to clarify parameter meanings.
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 verb 'Check' and the resource 'Apple Reminders authorization status', and it clarifies the purpose by indicating that it returns whether remindctl has permission. This distinguishes it from sibling tools that manage reminders data, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to verify authorization before or after other reminder operations, but it does not explicitly state when to use it or mention alternatives. Since there are no sibling tools that perform the same function, the implied usage is clear, but no explicit guidance is provided.
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 include destructiveHint: true, and the description adds 'This action cannot be undone,' reinforcing irreversibility beyond the annotation. It also specifies that all reminders are deleted, which is a destructive consequence. This is useful behavioral context, though it does not cover potential permission requirements or other edge cases.
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 and 15 words, immediately stating the action and its consequence. It is front-loaded with the key verb and resource, and every sentence adds value. There is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool with annotations covering the safety profile, the description is complete. It covers the action, the scope (list plus reminders), and irreversibility. No output schema exists, but none is necessary given the simplicity. The description provides all needed context for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the 'name' parameter, with a description 'Name of the list to delete.' The tool description does not add any additional parameter semantics beyond the schema, 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 identifies the tool's function: 'Delete a reminder list and all its reminders.' It uses a specific verb and resource, and the note about deleting all reminders distinguishes it from sibling tools like delete-reminders, which handles individual reminders. This is a clear and unambiguous purpose statement.
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 deleting an entire list, but it does not explicitly state when to use this tool versus alternatives like delete-reminders. No exclusions or alternative tools are mentioned. The context is clear about the scope, but lacks explicit guidance on choosing this tool over others.
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?
The annotation already marks destructiveHint: true, and the description adds 'This action cannot be undone,' which is critical behavioral context beyond the annotation. It discloses irreversibility but no other side effects, which is sufficient for a simple delete tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that are front-loaded with the action and include a crucial caveat about irreversibility. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool with a destructiveHint annotation and a clear reference to show output for indices, the description covers all necessary context. The lack of an output schema is acceptable for a destructive action, but it could have mentioned what happens to related data or confirmations.
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 schema already documents the 'ids' parameter with a matching description, so schema coverage is 100%. The description repeats the same information without adding new semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes reminders, with a specific verb ('delete') and resource ('reminders'). It differentiates from sibling tools like complete-reminders by emphasizing permanent removal, and the reference to index numbers from show output adds precise scope.
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?
It provides context that reminders are referenced by index numbers from show output or ID/UUID prefixes, implying a prerequisite viewing step. However, it does not explicitly contrast with alternatives like complete-reminders or state when not to use this tool.
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?
The description discloses the return fields (ID, title, reminder count, overdue count), adding clarity about behavior. Since there are no annotations, this information helps the agent understand what to expect. It does not state limitations or side effects, but as a read-only list operation, the coverage is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the action, the second specifies the return fields. No filler, appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and no output schema, the description fully covers the tool's purpose and expected return data, making it complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information because none are needed.
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 'List all reminder lists' with a specific verb and resource. It also lists the return fields, distinguishing it from sibling tools like show-reminders (which likely shows reminders within a list) and create-list.
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 clearly indicates this is the tool for listing all reminder lists, providing context for when to use it. It does not explicitly mention alternatives or exclusions, but the simplicity of the operation makes the usage unambiguous.
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:

[![reminders-mcp MCP server](https://glama.ai/mcp/servers/mikakoivisto/reminders-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mikakoivisto/reminders-mcp)

Score Badge

Copy to your README.md:

[![reminders-mcp MCP server](https://glama.ai/mcp/servers/mikakoivisto/reminders-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mikakoivisto/reminders-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/mikakoivisto/reminders-mcp'

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