Ganty MCP
Server Details
Gantt chart SaaS with server-side critical path and dependency-aware shift-impact tools, plus CRUD.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 15 of 15 tools scored. Lowest: 2.7/5.
Each tool targets a distinct action on a specific resource (project, task, milestone, dependency, workspace). There is no overlap—for example, get_task and update_task are clearly different operations, and list_milestones vs create_milestone are separate actions.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_project, list_tasks, add_dependency). Verbs are uniform and predictable, making the set easy to navigate.
15 tools is well-scoped for a project management server. It covers CRUD for projects and tasks, plus milestones, dependencies, progress tracking, critical path analysis, and rescheduling—neither too few nor too many.
The tool surface covers essential lifecycle operations for projects, tasks, and milestones, including advanced features like critical path and rescheduling. However, minor gaps exist: no update_milestone, delete_milestone, list_dependencies, or remove_dependency; these are noticeable but not critical.
Available Tools
15 toolsadd_dependencyAInspect
Add a finish-to-start dependency between two tasks in the same project.
| Name | Required | Description | Default |
|---|---|---|---|
| lagDays | No | Optional lag in days after predecessor finishes | |
| successorId | Yes | Task that can start after predecessor finishes | |
| predecessorId | Yes | Task that must finish first |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only states the action but fails to disclose behaviors like cycle checking, error handling, or whether dependencies are idempotent. For a mutation tool, more disclosure is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the action, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 parameters, the description is adequate but lacks behavioral details and explicit scoping (same project is implied). It does not leverage sibling context to differentiate usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by specifying the dependency type (finish-to-start), which is not in the schema descriptions. However, it does not add further parameter context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a finish-to-start dependency between two tasks, specifying the dependency type and the scope (same project). This distinguishes it from siblings like get_critical_path or create_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting dependencies but provides no explicit guidance on when to use vs alternatives, such as get_critical_path for viewing dependencies or reschedule_and_propagate for managing effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_milestoneCInspect
Add a milestone (key date) to a project.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | YYYY-MM-DD | |
| name | Yes | ||
| color | No | Hex color (defaults to #f59e0b) | |
| projectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks disclosure of behavioral traits such as whether creation is idempotent, if duplicates are allowed, or any side effects (e.g., notification triggers). The description only states a generic creation action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that gets to the point without waste. It sacrifices completeness for brevity, which is a trade-off but not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (3 required), no output schema, and no annotations, the description is insufficient. It does not explain return values, error handling, or any constraints (e.g., valid milestone names, date format confirmation with the schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with descriptions for 'date' and 'color' but not for 'name' and 'projectId'. The tool description does not add any parameter meaning beyond what the schema already states, failing to compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'milestone (key date)', and the context of 'to a project' distinguishes it clearly from sibling tools like 'list_milestones' or 'create_task'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'create_task' or 'add_dependency'. There is no mention of prerequisites, scope, or conditions that favor this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_projectAInspect
Create a new project in a workspace. Returns the created project. Subject to plan-based project count limits.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Project name | |
| color | No | Hex color (e.g. #3b82f6). Defaults to blue. | |
| endDate | No | YYYY-MM-DD. Optional. | |
| startDate | No | YYYY-MM-DD. Defaults to today. | |
| description | No | ||
| workspaceId | Yes | Workspace ID (UUID) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses mutation (create), return value, and a constraint. However, it lacks details on permissions, error handling, or side effects like overwriting existing projects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the main action. Every sentence adds value: creation, return, constraint. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with 6 parameters and no output schema, the description covers core purpose and a constraint but omits prerequisites (e.g., workspace existence) and output details. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83% and the description adds no additional context beyond what is already in the schema parameter descriptions. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new project in a workspace' with a specific verb and resource. It distinguishes from siblings like create_task and create_milestone by naming the exact operation and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Subject to plan-based project count limits,' which implies a restriction but does not provide explicit guidance on when to use this tool versus alternatives like create_task or add_dependency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_taskBInspect
Create a new task in a project. Dates must be in YYYY-MM-DD format. End date is exclusive (a 1-day task has end = start + 1 day).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| color | No | Hex color (e.g. #3b82f6) | |
| status | No | ||
| endDate | Yes | YYYY-MM-DD (exclusive end) | |
| parentId | No | Parent task ID for hierarchy | |
| progress | No | ||
| projectId | Yes | ||
| startDate | Yes | YYYY-MM-DD | |
| assigneeId | No | Profile ID of the assignee | |
| description | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden. It discloses the exclusive end date behavior and date format, but does not mention other behavioral details like required permissions, response format, or side effects, which are important for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loaded with purpose. It is efficient but could be improved with minor structuring for readability, though it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description is incomplete. It lacks information about return values, constraints on required fields, and behavior of optional parameters like parentId, which are necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, meaning half of the parameters lack descriptions. The description only adds semantic value for endDate (exclusive) and startDate (format), but fails to explain other parameters like parentId, assigneeId, progress, or color, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new task in a project' with a specific verb and resource. It distinguishes from siblings like create_milestone and update_task by context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like update_task or create_milestone, nor any prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_projectAInspect
Permanently delete a project. All tasks, milestones, and dependencies inside the project are also removed. This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses destructive behavior (permanent removal of project and contained items). Additional details like authorization requirements would improve it, but it is sufficient for a simple delete operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, no unnecessary words. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one param and no output schema, the description covers all essential information: action, scope, and irreversibility. Fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one required param (projectId, string) with 0% description coverage. Description does not explain the parameter beyond the action context, but the param is self-explanatory given the tool purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (permanently delete a project) and what is affected (all tasks, milestones, dependencies). It distinguishes from sibling tools like delete_task and create_project by specifying scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description indicates when to use (to delete a project permanently) and warns it cannot be undone. Lacks explicit comparison to alternatives but context from sibling tools makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_taskAInspect
Delete a task. Child tasks and dependencies are removed as well.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that child tasks and dependencies are removed, which is key behavioral information. No annotations exist, so description carries full burden, but it omits details like permanence, authorization needs, or whether deletion is soft or hard.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main action, no filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with one parameter and no output schema, the description covers the core behavior and notable side effects. It could mention the return value or success indicator, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning for the single parameter 'taskId'. It simply says 'Delete a task' without explaining what format the taskId should be or where to find it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool deletes a task, and distinguishes from siblings like create_task or update_task by specifying that child tasks and dependencies are also removed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when a task needs deletion, and warns about side effects, but lacks explicit when-not-to-use or alternative tools (e.g., if you want to keep dependencies).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_critical_pathAInspect
Calculate the critical path of a project on the Ganty side and return it as data (don't ask the model to reason over raw task lists). Uses forward/backward CPM with progress-aware remaining duration. Returns critical_path tasks in order, per-task earliest/latest start/finish + slack, project_end_date, and total_duration_days. v1 limitations: Finish-to-Start dependencies only (Ganty has no other types), calendar days by default (business_days=true skips Sat/Sun but no holiday table), ignores multi-period segments, no resource calendars. Returns { error: 'cyclic_dependency', cycle } if a cycle is detected.
| Name | Required | Description | Default |
|---|---|---|---|
| as_of_date | No | YYYY-MM-DD. Start point for projecting remaining work. Defaults to today. | |
| project_id | Yes | Project ID (UUID) | |
| business_days | No | If true, skip Saturday and Sunday in duration calculations. National holidays are still treated as working days (v1 has no holiday table). Defaults to false. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses algorithm (CPM with progress-aware duration), return fields, and detailed v1 limitations (dependency type, calendar handling, no holiday table, cycle detection). Highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: purpose first, then algorithm, return fields, limitations. Every sentence adds value with no wasted words. Front-loaded efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description fully explains return values (critical path tasks, slack, dates, duration) and error case. Covers all essential aspects for a complex analytical tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline 3. Description adds minimal extra meaning beyond schema (e.g., business_days skip Sat/Sun is already in schema). Does not elaborate on as_of_date default beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states that the tool calculates the critical path of a project on the Ganty side and returns it as data, with explicit instruction not to ask the model to reason over raw task lists. Distinct from sibling tools like list_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool (need critical path data) and includes 'don't ask the model to reason' guideline. Mentions v1 limitations that inform usage. Lacks explicit comparison to sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_taskAInspect
Get detailed information about a single task, including assignees and dependencies.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | Task ID (UUID) |
Tool Definition Quality
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 correctly implies a read-only operation but does not disclose error behavior (e.g., if task not found), authentication requirements, or rate limits. Basic transparency is present, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core purpose. It is front-loaded and efficient, but could be slightly more structured (e.g., listing key return fields) without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter retrieval tool with no output schema and no annotations, the description covers the essential aspects: what action, what resource, and what kind of detail is returned. It is sufficient for the agent to understand the tool's purpose, though a mention of the output structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the parameter 'taskId' is described as 'Task ID (UUID)'). The description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('get detailed information'), the resource ('single task'), and the scope ('including assignees and dependencies'). It clearly distinguishes from sibling tools like list_tasks (which lists multiple tasks) and create_task (which creates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when details of a single task are needed, but does not explicitly state when to use or avoid this tool, nor does it mention alternatives. An agent could infer context from sibling names, but explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_milestonesCInspect
List milestones in a project (key dates such as launch or review gates).
| Name | Required | Description | Default |
|---|---|---|---|
| projectId | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral details such as read-only nature, side effects, or ordering. With no annotations, the description carries full burden and fails to disclose even basic traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. However, it could include more useful information without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool, the description provides context by defining milestones as key dates. It lacks information about prerequisites, output format, or any constraints, but it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not mention the projectId parameter. It adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists milestones in a project and gives concrete examples (key dates such as launch or review gates). It distinguishes from sibling tools like create_milestone and list_projects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. It does not mention sibling tools like get_critical_path or when not to use list_milestones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_projectsAInspect
List all projects in a workspace (excluding archived).
| Name | Required | Description | Default |
|---|---|---|---|
| workspaceId | Yes | Workspace ID (UUID) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It reveals that archived projects are excluded, which is a behavioral trait. However, it does not mention other behaviors such as read-only nature (implied by 'list'), pagination, authentication requirements, or rate limits. The disclosure is minimal but acceptable for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the essential information without redundancy. It is front-loaded with the action and resource, making it quick to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description adequately states the action and filter. However, it lacks details about the output structure (e.g., returns list of project objects) and does not mention any ordering or pagination behavior. This is not critical but leaves minor gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – the single parameter 'workspaceId' is fully described in the schema as a UUID. The description does not add any additional meaning beyond the schema, meeting the baseline expectation for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' and resource 'projects' with clear scope 'in a workspace (excluding archived)'. It distinguishes from sibling tools like list_tasks and list_workspaces by naming the exact resource and filter condition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does ('list all projects in a workspace excluding archived') but provides no guidance on when to use it versus alternatives (e.g., list_tasks, create_project) or when not to use it (e.g., if archived projects are needed). The sibling list offers implicit context but no explicit directions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tasksAInspect
List tasks in a project. Supports optional filtering by name (search), status, and assignee.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Filter task name by case-insensitive substring | |
| status | No | ||
| projectId | Yes | Project ID (UUID) | |
| assigneeId | No | Filter by assignee profile ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states basic behavior (listing) without disclosing side effects, pagination, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose, but could benefit from slight restructuring for clarity on filter combinations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is too brief; lacks context on pagination, sorting, and error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds value beyond schema by specifying 'case-insensitive substring' for search and naming all filterable fields, complementing the 75% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (list), resource (tasks), and scope (in a project), distinguishing it from siblings like list_projects or list_milestones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions optional filtering but provides no guidance on when to use this tool vs alternatives (e.g., get_task for single task) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_workspacesAInspect
Get all workspaces the authenticated user is a member of.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It correctly indicates a read-only 'get' operation but omits important details such as pagination, result limits, or the structure of returned data (no output schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the tool's action and scope. No extraneous words are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters), the description adequately states its purpose. However, it falls short by not specifying the output format or any limitations, which would be beneficial for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100%. The description adds no parameter-specific information beyond the schema, resulting in the baseline score of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all workspaces the authenticated user is a member of' uses a specific verb ('Get'), identifies the resource ('workspaces'), and precisely scopes the result to the authenticated user's memberships, clearly differentiating from any potential broader listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. While sibling tools are unrelated to workspace listing, the description does not state that this is the primary means to retrieve workspaces for the user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reschedule_and_propagateAInspect
Compute the downstream impact of shifting a single task. Default is dry_run (no DB writes); set mode='commit' to actually persist the changes. Cascades forward only (no pull): successors are pushed only if their predecessor's new end + lag would violate their current start. Tasks with progress=100 are treated as pinned; pass pinned_task_ids for additional pins. When a pin would be violated, the change is recorded in 'conflicts' and not propagated further. In mode='commit', if any conflicts exist nothing is written (all-or-nothing transaction). Same v1 limitations as get_critical_path: FS only, calendar days by default, no holiday table, ignores multi-period segments.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | dry_run (default): compute and return; do not modify DB. commit: write to DB in a single transaction, but only if no conflicts. Audit logged on commit. | |
| shift | No | Relative shift like '+3d' (push back) or '-2d' (pull earlier). Specify exactly one of shift or new_start_date. | |
| task_id | Yes | Task ID (UUID) to shift | |
| business_days | No | If true, skip Sat/Sun in duration math. Defaults to false. | |
| new_start_date | No | Absolute new start date as YYYY-MM-DD. Specify exactly one of shift or new_start_date. | |
| pinned_task_ids | No | Additional task IDs to treat as pinned (in addition to progress=100 tasks). | |
| respect_dependencies | No | If false, only the named task moves; successors are not cascaded. Default true. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully burdens behavioral disclosure. It details dry_run default, commit transaction semantics, conflict handling, pinning, cascading rules, and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense paragraph with all necessary information. Could be slightly more structured (e.g., bullet points) but remains clear and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so return values are implied but not explicit. The description covers behavior thoroughly, including conflicts and limitations, making it largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds significant value by explaining modes, pinning, cascading, transaction behavior, and edge cases beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes the downstream impact of shifting a task, with dry_run and commit modes. It distinguishes itself from siblings like get_critical_path by referencing shared limitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use dry_run vs commit, and describes cascading and pinning behavior. However, it does not explicitly contrast with alternatives like update_task or set_task_progress.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
set_task_progressAInspect
Update the progress percentage of a task (0-100). Status is auto-derived: 0=not_started, 1-99=in_progress, 100=done.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | ||
| progress | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the auto-derivation of status from progress values, which is a key behavioral trait not in the schema. No annotations are provided, so the description carries full burden; it adds value by explaining side effects of the progress value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence explaining the action and another explaining the status derivation. No wasted words, information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the description covers the main behavioral aspects. It could mention error conditions (e.g., invalid taskId) but remains adequate for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description must compensate. It explains the progress parameter's range and its effect on status, adding meaningful context. The taskId parameter is not described but is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it updates the progress percentage of a task and explains the auto-derived status. The verb 'update' and resource 'task progress' are specific, and it distinguishes from the sibling 'update_task' which likely handles multiple fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for setting progress and explains the status mapping, which guides when to use it. However, it does not explicitly state when not to use or mention alternatives like 'update_task' for other changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_taskAInspect
Update fields of an existing task. Only provided fields will be modified.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| color | No | ||
| status | No | ||
| taskId | Yes | ||
| endDate | No | YYYY-MM-DD | |
| progress | No | ||
| startDate | No | YYYY-MM-DD | |
| assigneeId | No | null to unassign | |
| description | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially discloses behavior (partial update) but does not mention error handling, return values, or validation, leaving gaps for a tool with 9 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loaded with the primary action, and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 9 parameters, no output schema, and no annotations, the description is too minimal. It omits crucial context about success responses, error conditions, and parameter interdependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level information beyond the input schema, which already has low coverage (33%). It fails to compensate for undocumented parameters like name, color, progress, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'existing task', distinguishing it from sibling tools like create_task, delete_task, and get_task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Only provided fields will be modified' which implies partial updates, but lacks guidance on when to use this tool versus set_task_progress or other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!