Routine

Official

by routineco

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes, but there is some overlap between eventDay and eventTimeline (both provide daily event views) and between taskDay, taskUnplanned, and taskUpcoming (all list tasks with different filters). The descriptions help differentiate them, but an agent might occasionally misselect between these similar tools.
Naming Consistency4/5
The naming is mostly consistent with a verb_noun pattern (e.g., calendarGet, eventGet, taskCreateSimple), but there are minor deviations like authProfile (noun_noun), calendarAll (noun_adjective), and peopleByEmail (noun_preposition_noun). These deviations are readable but break the overall pattern slightly.
Tool Count4/5
With 18 tools, the count is slightly high but reasonable for a productivity/calendar domain covering calendars, events, pages, people, and tasks. It feels comprehensive rather than bloated, though it borders on being heavy for an MCP server.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for its domains: calendars (list, get), events (list by day, get, timeline), pages (list, get), people (get by email/id), and tasks (create, get, update, complete/uncomplete, list by various filters). There are no obvious gaps, and agents can handle typical workflows without dead ends.
Average 2/5 across 18 of 18 tools scored. Lowest: 1.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed 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

Behavior1/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 of behavioral disclosure. However, it gives no information about what the tool does (e.g., read, write, delete), its effects, permissions required, or response format, failing to compensate for the lack of structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise with only two words, the description is under-specified rather than efficiently informative. It lacks any structure or front-loading of key details, making it ineffective despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's unknown complexity (implied by sibling tools like 'calendarAll'), no annotations, no output schema, and a parameter with 0% coverage, the description is completely inadequate. It fails to provide any meaningful information needed for an agent to understand or use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its single required parameter 'id', and the description adds no meaning or context about this parameter. It does not explain what 'id' represents (e.g., a calendar identifier) or how to use it, leaving the parameter completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'A calendar.' is a tautology that merely restates the tool name without specifying any action or purpose. It provides no verb or indication of what the tool does (e.g., retrieve, create, update), making it completely uninformative and misleading for an AI agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention any context, prerequisites, or distinctions from sibling tools like 'calendarAll' or 'eventGet', leaving the agent with no basis for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. 'An event.' gives no indication of whether this is a read, write, or destructive operation, what permissions are required, what happens on success/failure, or any rate limits. It fails to describe any behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with two words, this is under-specification rather than effective brevity. The description is too sparse to be useful, failing to convey essential information that would help an agent use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a parameter with 0% schema coverage, the description is completely inadequate. It doesn't explain what the tool does, how to use it, what it returns, or any behavioral characteristics, leaving critical gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about parameters. With 0% schema description coverage and one required parameter 'id', the description doesn't explain what 'id' represents, its format, or where to obtain it. It adds zero value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'An event.' is a tautology that merely restates the tool name 'eventGet' without specifying what action it performs. It doesn't indicate whether this retrieves, creates, modifies, or deletes events, nor does it distinguish it from sibling tools like 'eventDay' or 'eventTimeline'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention context, prerequisites, or exclusions, leaving the agent with no information about appropriate usage scenarios compared to sibling tools like 'eventDay' or 'calendarGet'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. 'A task.' reveals nothing about whether this is a read or write operation, what permissions might be required, what happens when invoked, or what the response contains. For a tool with a required parameter and no annotation coverage, this represents a complete failure to describe behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this represents under-specification rather than effective brevity. The description doesn't earn its place by providing necessary information. A single vague phrase fails to establish any meaningful context for tool selection and use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a required parameter, no annotations, no output schema, and multiple similar sibling tools, the description is completely inadequate. It provides no information about purpose, usage, behavior, parameters, or return values. For a tool in this context, the description fails to provide even minimal necessary information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, meaning the single required 'id' parameter is completely undocumented in the schema. The description 'A task.' provides no information about what the 'id' parameter represents, what format it should have, or where to obtain it. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'A task.' is a tautology that merely restates the tool name without specifying what action it performs. It doesn't distinguish this tool from its many sibling task tools (taskComplete, taskCreateSimple, taskDay, etc.), nor does it indicate whether this retrieves, modifies, or analyzes a task. The description fails to provide a clear verb+resource combination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. With multiple sibling task tools available (taskComplete, taskCreateSimple, taskDay, taskGet, taskUncomplete, taskUnplanned, taskUpcoming, taskUpdate), there's no indication of what differentiates 'taskGet' from these other options. No context, prerequisites, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. However, it fails to describe any behavioral traits—it doesn't indicate whether this is a read-only operation, what happens if the ID is invalid, potential error conditions, or authentication requirements. The description is too vague to inform the agent about how the tool behaves.
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, concise sentence that is front-loaded with the core idea. There is no wasted verbiage, making it efficient in terms of length. However, it lacks structural elements like examples or clarifications that could enhance understanding without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a retrieval tool with no annotations, no output schema, and poor parameter documentation, the description is incomplete. It doesn't explain what is returned (e.g., contact details), error handling, or usage context, leaving significant gaps for the agent to infer behavior and results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, meaning the schema provides no semantic information about the 'id' parameter. The description does not compensate by explaining what the 'id' represents (e.g., a contact identifier, format, or source), leaving the parameter's meaning entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'The contact with the given id' is a tautology that essentially restates the tool name 'peopleGet' without specifying the action. It lacks a clear verb (like 'retrieve' or 'fetch') and doesn't distinguish this tool from sibling tools like 'peopleByEmail' or 'pageGet'. The purpose is implied but not explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention sibling tools like 'peopleByEmail' for email-based lookups or 'pageGet' for retrieving pages, nor does it specify prerequisites such as needing a contact ID. The description offers no context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. However, it offers no information about what the tool does beyond the tautological statement. There's no mention of whether it's a read or write operation, authentication needs, rate limits, or what happens when invoked. This leaves the agent with no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence, 'The events on a given day.' While this under-specifies the tool's functionality, it is front-loaded and wastes no words, earning full marks for conciseness. However, this brevity contributes to low scores in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 required parameters, no annotations, no output schema), the description is completely inadequate. It fails to explain the tool's purpose, usage, behavior, or parameters, leaving the agent with insufficient information to select and invoke the tool correctly. The lack of output schema further exacerbates this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no meaning beyond what the schema provides—it doesn't explain what 'date', 'filter', or 'secondary' mean or how they affect the tool's behavior. With 3 required parameters and no compensation in the description, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'The events on a given day' is a tautology that essentially restates the tool name 'eventDay' without specifying the action. It doesn't clearly state what the tool does (e.g., 'retrieve', 'list', or 'display' events) or distinguish it from sibling tools like 'eventGet' or 'eventTimeline'. The purpose is vague rather than specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There's no mention of context, prerequisites, or comparisons to sibling tools such as 'eventGet' or 'eventTimeline'. Without any usage instructions, the agent lacks direction on appropriate application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. 'Get a page' implies a read operation, but it doesn't specify whether this requires authentication, what happens on failure, if there are rate limits, or the format of the returned data. For a tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence 'Get a page.', which is front-loaded and wastes no words. While under-specified, it efficiently conveys the basic action without unnecessary elaboration, earning full marks for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (1 parameter, no annotations, no output schema), the description is incomplete. It doesn't explain what a 'page' is in this context, how to use the tool effectively, or what to expect in return. For a tool with minimal structured data, the description should provide more context but fails to do so.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, and the description adds no meaning beyond the schema. It doesn't explain what the 'id' parameter represents, its format, or how to obtain it. With low schema coverage, the description fails to compensate, leaving the parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a page' is a tautology that restates the tool name 'pageGet' with minimal elaboration. While it indicates the verb 'Get' and resource 'page', it lacks specificity about what kind of page or what information is retrieved. It doesn't distinguish this tool from sibling tools like 'pageAll' or 'eventGet', leaving the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 doesn't mention sibling tools like 'pageAll' for listing pages or 'eventGet' for events, nor does it specify prerequisites or contexts for usage. This absence of guidance makes it misleading for an AI agent to select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to do so. 'Patch a task' implies a mutation but does not clarify permissions, side effects, error handling, or response format, offering no transparency beyond the basic action.
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 a single sentence, 'Patch a task.', which is front-loaded and wastes no words. However, this brevity contributes to under-specification rather than effective communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters with nested objects, no annotations, no output schema), the description is completely inadequate. It does not explain the tool's behavior, parameters, or output, leaving critical gaps for a mutation tool in a system with multiple sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning parameters (id, patch, confirm) are undocumented in the schema. The description adds no semantic information about these parameters, such as their roles, formats, or constraints, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Patch a task' restates the tool name 'taskUpdate' with minimal elaboration, making it tautological. It specifies the verb ('patch') and resource ('task') but lacks detail on what patching entails or distinguishes it from siblings like taskComplete or taskCreateSimple, leaving the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as taskComplete, taskCreateSimple, or taskGet. The description offers no context, prerequisites, or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 of behavioral disclosure. 'All pages' gives no indication of whether this is a read or write operation, what permissions might be required, whether it's safe or destructive, or what the expected output format might be. The description fails to provide any behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this represents under-specification rather than effective conciseness. The description fails to provide essential information that would help an agent understand and use the tool correctly. Every word should earn its place, but here the words don't provide meaningful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and a minimal description, this is completely inadequate for a tool that presumably returns some kind of data. The description doesn't explain what 'pages' are, what format they're returned in, or what the scope of 'all' encompasses. For a tool with no structured metadata, the description should provide much more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description doesn't need to compensate for any parameter gaps. The baseline for zero parameters with complete schema coverage is 4, as there's nothing additional the description could reasonably add about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'All pages' is a tautology that essentially restates the tool name 'pageAll'. It doesn't specify what action the tool performs (list? retrieve? display?) or what resource 'pages' refers to. While it indicates the tool deals with pages, it lacks a clear verb and doesn't distinguish from sibling tools like 'pageGet'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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. There's no mention of context, prerequisites, or comparison with sibling tools like 'pageGet'. The agent receives no help in determining appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. 'Complete a task' implies a mutation operation but doesn't specify what completion means (marking as done, archiving, changing status), whether it's reversible (note the 'taskUncomplete' sibling exists), what permissions are required, or what the response contains. For a mutation tool with zero annotation coverage, this is completely inadequate.
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 maximally concise at just three words. While severely under-specified, it contains no redundant or unnecessary language. Every word ('Complete', 'a', 'task') contributes directly to the core purpose statement without any fluff or structural issues.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool (completing tasks) with no annotations, 0% schema description coverage, no output schema, and multiple sibling tools, the description is completely inadequate. It doesn't explain what completion means, how it differs from other task operations, what the parameter represents, what happens after completion, or any behavioral aspects. The description fails to provide the minimal context needed for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its single required 'id' parameter, and the tool description provides absolutely no information about parameters. The description doesn't mention the 'id' parameter at all, nor does it explain what format the ID should be, where to obtain it, or what task it refers to. With zero schema coverage and no parameter information in the description, this fails to provide basic parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Complete a task' is a tautology that essentially restates the tool name 'taskComplete' without adding meaningful specificity. While it indicates the verb 'complete' and resource 'task', it doesn't distinguish this tool from its sibling 'taskUncomplete' or explain what completion entails. This minimal description provides only basic purpose information without differentiation.
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. With siblings like 'taskUncomplete', 'taskUpdate', and 'taskCreateSimple' available, there's no indication of when completion is appropriate versus updating or creating tasks. The description lacks any context about prerequisites, timing considerations, or relationships to other task operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers none. 'Uncomplete a task' implies a mutation operation (changing task status), but doesn't specify permissions needed, whether this is reversible, what happens to completion timestamps, or error conditions. It provides zero behavioral context beyond the basic action implied by the name.
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 at just three words. While severely under-specified, it's not verbose or repetitive—every word contributes to stating the core action. There's no wasted text, though the brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a mutation tool with no annotations, 1 undocumented parameter, and no output schema, the description is completely inadequate. It doesn't explain what 'uncompleting' means operationally, what the parameter requires, what the tool returns, or how it differs from sibling tools. The agent lacks essential information to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters at all, while the schema has 1 required parameter ('id') with 0% description coverage. The description doesn't explain what 'id' represents (task identifier format, source, constraints), leaving the parameter completely undocumented. With low schema coverage and no compensation in the description, this is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Uncomplete a task' is a tautology that essentially restates the tool name 'taskUncomplete'. It specifies the verb ('Uncomplete') and resource ('a task'), but doesn't provide any meaningful differentiation from what the name already conveys. It doesn't explain what 'uncompleting' means operationally or how it differs from related operations.
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 about when to use this tool versus alternatives. It doesn't mention prerequisites (like needing a previously completed task), contrast with sibling tools like 'taskComplete' or 'taskUpdate', or indicate appropriate contexts. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides no information about what the tool actually does. 'All calendars' doesn't indicate whether this is a read operation, a write operation, what permissions might be required, what format the output takes, or any behavioral characteristics. This is completely inadequate for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just two words, this is a case of under-specification rather than effective conciseness. The description fails to convey essential information about the tool's purpose and behavior. Every word should earn its place, but these two words don't provide meaningful guidance to an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description 'All calendars' is completely inadequate. It doesn't explain what the tool does, what behavior to expect, what format results will take, or how it differs from sibling tools. Given the complexity of calendar operations and the lack of structured documentation, this description fails to provide the necessary context for an AI agent to use the tool effectively.
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 input schema has 100% description coverage (though empty). The description doesn't need to compensate for any parameter documentation gaps. The baseline for zero parameters is 4, as there are no parameters whose semantics need explanation beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'All calendars' is a tautology that essentially restates the tool name 'calendarAll' without specifying what action the tool performs. It doesn't indicate whether this tool lists, retrieves, displays, or manages calendars. While it identifies the resource (calendars), it lacks a clear verb to define the tool's function.
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 about when to use this tool versus alternatives. With sibling tools like 'calendarGet' and 'eventDay' available, there's no indication whether 'calendarAll' is for listing all calendars, retrieving all calendar data, or some other purpose. No context about prerequisites, timing, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. 'Main user identity' doesn't indicate whether this is a read operation, write operation, or something else. It doesn't disclose authentication requirements, rate limits, side effects, or what the tool actually returns. For a tool with zero annotation coverage, this description is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, but this brevity comes at the cost of meaningful information. While it's not verbose or repetitive, it's under-specified rather than appropriately concise. The single phrase doesn't provide enough substance to be considered well-structured or helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this tool has no annotations, no output schema, and a minimal description, the overall context is severely lacking. The description doesn't explain what 'Main user identity' means in practical terms, what the tool returns, or how it should be used in relation to the many sibling tools. For a tool that presumably handles authentication or user identity (a critical function), this description is incomplete.
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 with 100% schema description coverage, so the baseline is 4. The description doesn't need to compensate for undocumented parameters since there are none. While the description doesn't add parameter-specific information (because there are no parameters), it doesn't detract from the complete schema coverage either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Main user identity' is a tautology that essentially restates the tool name 'authProfile' without specifying what the tool actually does. It doesn't indicate whether this retrieves, sets, verifies, or manages authentication profiles. The description lacks a clear verb-action-resource structure that would explain the tool's function.
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 the 16 sibling tools listed. There's no indication of whether this should be called before other operations, what context it's appropriate for, or what alternatives might exist for authentication or profile management. The agent receives no usage context from this description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It doesn't indicate whether this is a read-only operation, what permissions might be required, whether it returns past/future events, or any rate limits. The description is completely silent on behavioral 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 with just four words, making it easy to parse quickly. There's no wasted language or unnecessary elaboration, though this brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what an 'agenda view' entails, what data it returns, how events are formatted, or any limitations. The minimal description leaves too many questions unanswered for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its single 'date' parameter, and the tool description provides no information about what format the date array should be in (e.g., [year, month, day]), what timezone applies, or whether it accepts relative dates. The description fails to compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Agenda view for a day' clearly indicates this tool displays events for a specific day, which is a specific purpose. However, it doesn't distinguish this from sibling tools like 'eventDay' or 'calendarGet', leaving ambiguity about how it differs from similar calendar/event tools.
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 'eventDay', 'calendarGet', or 'calendarAll'. It doesn't specify whether this is for personal calendars, shared calendars, or what type of events it displays, offering no contextual usage information.
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 of behavioral disclosure. The description doesn't reveal any behavioral traits: it doesn't specify if this is a read-only lookup, if it requires authentication, what happens when no contact is found, or any rate limits. It merely describes the input-output relationship without operational details.
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, concise sentence that gets straight to the point without unnecessary words. It's appropriately sized for a simple lookup tool, though it could be more informative. There's no structural waste, but it's under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no annotations, no output schema), the description is incomplete. It doesn't explain what the tool returns (e.g., contact details, an error if not found), how it behaves, or when to use it. For a lookup tool with no structured output documentation, the description should provide more operational 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?
The description implies the parameter 'email' is used to identify a contact, which adds some meaning beyond the schema (which has 0% description coverage and only specifies the parameter name and type). However, it doesn't clarify the expected format of the email or any validation rules. With one parameter and low schema coverage, the description provides basic context but lacks depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'The potential contact owning this email address' is a tautology that essentially restates the tool name 'peopleByEmail' without specifying the action. It doesn't clearly state what the tool does (e.g., 'look up', 'retrieve', 'search for', or 'find' a person by email). The description is vague about the actual operation being performed.
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. Given sibling tools like 'peopleGet' (which likely retrieves people by ID rather than email), there's no indication of when to choose one over the other. No context about prerequisites, limitations, or appropriate scenarios is mentioned.
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 of behavioral disclosure. It mentions sorting but doesn't cover critical aspects like whether this is a read-only operation, if it requires authentication, what happens with invalid input, or the response format. This leaves significant gaps for a tool with parameters.
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 conveys the core functionality and sorting logic without unnecessary words. It's appropriately sized for a simple tool, though it could be more front-loaded by explicitly stating the action (e.g., 'Retrieve tasks for a day').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (1 parameter with 0% schema coverage, no annotations, no output schema), the description is incomplete. It doesn't explain the parameter's semantics, behavioral traits, or return values, making it inadequate for reliable tool invocation by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the 'day' parameter beyond implying it's used to specify a day. It doesn't explain the parameter's format (an array of three integers), purpose, or constraints, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves tasks for a specific day and mentions the sorting order (starred < default < completed/ignored), which clarifies the verb (retrieve/sort) and resource (tasks). However, it doesn't specify the exact action (e.g., 'retrieve' or 'list') or distinguish it from siblings like taskGet or taskUpcoming, making it somewhat vague.
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 taskGet, taskUpcoming, or eventDay. It lacks context on prerequisites, exclusions, or specific scenarios where this tool is preferred, leaving the agent to infer usage based on the name alone.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Unplanned tasks' implies a read operation (likely listing or retrieving), but doesn't confirm if it's safe, destructive, or requires authentication. It doesn't describe return format, error conditions, or any behavioral traits like pagination or rate limits. The description adds minimal value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Unplanned tasks.') but this brevity comes at the cost of under-specification. While there's no wasted text, the single phrase fails to provide necessary context about the tool's function. It's front-loaded but insufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent simplicity (0 parameters, no output schema), the description is incomplete. It doesn't explain what the tool actually does operationally, what 'unplanned' means contextually, or what users can expect as output. With no annotations and minimal description, an agent would struggle to understand when and how to invoke this tool effectively.
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 with 100% schema description coverage, so the schema fully documents the absence of inputs. The description doesn't need to compensate for parameter documentation gaps. While it doesn't add any parameter-specific information (which isn't needed), it maintains the baseline appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unplanned tasks' is a tautology that essentially restates the tool name 'taskUnplanned'. It doesn't specify what action the tool performs (list? create? modify?) or what resource it operates on beyond the vague 'tasks'. While it distinguishes from some siblings like 'taskComplete' or 'taskCreateSimple', it doesn't clearly differentiate from 'taskDay' or 'taskUpcoming' which might also relate to task organization.
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. Given siblings like 'taskDay', 'taskGet', 'taskUpcoming', and 'taskUpdate', there's no indication whether this tool is for retrieving, creating, or managing unplanned tasks specifically. No context about prerequisites, timing, or workflow integration is mentioned.
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 mentions organization and sorting, implying a read-only operation, but doesn't disclose behavioral traits such as whether it requires authentication, has rate limits, or what the output format might be. This leaves significant gaps in understanding how the tool behaves.
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 conveys the core function without waste. It's front-loaded with the main action, though it could be slightly more structured by specifying the resource type. Overall, it's appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (implied organization and sorting), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'non-allocated' means, what items are returned, or any behavioral aspects, making it inadequate for the agent to fully understand the tool's context and usage.
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 information is needed. The description appropriately doesn't add param details, but it does imply the tool operates on 'non-allocated' items, which adds minimal semantic context beyond the schema. Baseline is 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool organizes and sorts non-allocated items by week and alphabetically, which gives a vague purpose. However, it doesn't specify what type of items (e.g., tasks) or what 'non-allocated' means in context, and it doesn't clearly distinguish from siblings like taskDay or taskUnplanned, making it somewhat ambiguous.
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 doesn't mention any context, prerequisites, or exclusions, and with siblings like taskDay and taskUnplanned, there's no indication of how this tool differs in usage, leaving the agent without clear direction.
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 full burden. It mentions the tool creates a task (implying mutation) and gives parameter warnings, but doesn't disclose behavioral traits like required permissions, whether creation is reversible, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence states purpose and primary usage, the second gives critical warnings. Every word earns its place, and the most important information is front-loaded.
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 creation tool with no annotations, no output schema, and a complex nested parameter structure, the description is incomplete. It provides good usage guidance but lacks behavioral context, return value information, and comprehensive parameter explanations. It's minimally adequate given the complexity.
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% schema description coverage, the description compensates by specifying that 'Usually you only need to pass the title' and warns against using integration_id or distant_task_id. This adds meaningful guidance beyond the complex schema, though it doesn't explain other parameters like notes, occurrence, parent, etc.
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 ('Create') and resource ('a task'), and specifies it's simplified for MCP. However, it doesn't explicitly distinguish this from sibling tools like taskUpdate or taskComplete, though the 'simplified' hint suggests differentiation.
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 provides explicit guidance on when to use this tool ('Usually you only need to pass the title') and when not to use it ('Do not try to pass the integration_id or distant_task_id'). This gives clear usage boundaries despite not mentioning specific sibling alternatives.
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:

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

Score Badge

Copy to your README.md:

[![mcp-server MCP server](https://glama.ai/mcp/servers/routineco/mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/routineco/mcp-server)

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/routineco/mcp-server'

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