Ganty MCP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of disclosure. It mentions the constraint 'in the same project' and specifies the dependency type, but does not disclose potential side effects such as duplicate handling, validation of task existence, or impact on scheduling. This is adequate but leaves significant behavioral unknowns.

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 front-loads the core action and constraints. Every word earns its place, with no redundancy or filler.

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 (3 parameters, no output schema), the description is complete enough for its purpose. It explains the action and the key project-scoping constraint. However, it could mention what happens if the tasks are not in the same project or if the dependency already exists, but this is not critical for a basic add 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?

Schema coverage is 100%, so the baseline is 3. The description adds the notion of 'finish-to-start' which aligns with the schema's parameter descriptions, but it does not provide additional meaning beyond what the schema already states for predecessorId and successorId.

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 a specific action ('Add a finish-to-start dependency') and the target resource ('between two tasks in the same project'). It distinguishes itself from sibling tools like create_task or update_task by focusing on task relationships, not task creation or editing.

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 clearly implies when to use the tool: when you need to link two tasks in a finish-to-start relationship. It doesn't explicitly mention alternatives or exclusions, but the context of sibling tools makes the use case obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 only says 'Add a milestone' with no mention of effects, permissions, duplicate handling, or return value—minimal transparency for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence with no redundancy, front-loaded with the verb and object. Every word earns its place.

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 no annotations and no output schema, the description omits usage context, return/response behavior, and parameter motivations. It relies entirely on the schema and sibling names, which is insufficient for a complete understanding.

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 descriptions cover only date and color (50% coverage), leaving projectId and name undocumented. The description does not compensate for these gaps and adds little parameter meaning beyond the phrase 'key date', which only weakly aligns with the date parameter.

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 uses specific verb 'Add' with resource 'milestone (key date)' and target 'to a project', clearly distinguishing from sibling tools like create_task and list_milestones. It tells exactly what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as create_task or list_milestones. Usage must be inferred from the resource name alone, with no explicit when-to-use or when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden. It discloses the return value and plan-based count limits, which is useful, but it omits permission requirements, idempotency, or error behavior when limits are exceeded. For a create tool, mutation is inherent, and the added constraints are valuable but not exhaustive.

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 action and resource, no filler. The plan-limit note is valuable and earns its place.

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 six-parameter create tool with no output schema and no annotations, the description provides key return-value information and a significant constraint (plan limits). The schema covers parameter semantics, making the description sufficiently complete for tool selection and 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 83%, so the baseline is 3. The description does not add parameter-specific meaning beyond what the schema already documents; it only adds a global plan-limit caveat.

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 'Create' with the resource 'a new project in a workspace,' clearly distinguishing it from sibling tools like create_task and create_milestone. It also states it returns the created project, adding precision.

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 when to use the tool (when creating a project rather than a task or milestone) but does not explicitly mention alternatives or exclusions. The plan-based limit is a caveat rather than usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses non-obvious behavior: date format (YYYY-MM-DD) and exclusive end date semantics (end = start + 1 for a 1-day task). This is valuable but does not cover other behavioral aspects like default values or return payload, so not a 5.

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 primary purpose, then the key date constraints. There is zero fluff and every sentence provides necessary operational detail.

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 operation with a rich schema and no output schema, the description covers the most error-prone aspect (date semantics) and clearly indicates the action. It omits details like defaults or required fields, but those are already visible in the schema, so the description is adequately complete for the tool's complexity.

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 already documents the date parameters, including the exclusive end note, so the description's date guidance partially duplicates schema info. The example clarifies the exclusivity but does not add meaning for the many other parameters (color, status, parentId, progress, etc.), which are undocumented in the description. This offsets the moderate 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?

The description clearly states the verb ("Create") and resource ("a new task in a project"), which distinguishes it from sibling tools like create_milestone and create_project. It is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use (creating tasks within projects) and includes important date-handling rules. It does not explicitly mention alternatives, but the context is sufficient given the tool name and sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and it does well by disclosing key behaviors: permanent deletion ('cannot be undone') and cascading removal of tasks, milestones, and dependencies. This goes beyond the basic schema and alerts the agent to the destructive, irreversible nature of the 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?

The description is concise, with two sentences that front-load the action and then add critical consequence details. Every sentence contributes necessary information without redundancy or fluff.

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 covers the essential aspects: what it deletes, the cascading effect, and irreversibility. It lacks mention of error handling or prerequisites, but these are less critical for a simple destructive operation and the description is adequate for an agent to decide when to invoke it.

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 does not mention the projectId parameter at all. While the parameter name and tool context make its purpose obvious, the description adds no explicit meaning or format guidance, 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.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Permanently delete a project' with a specific verb and resource, and further distinguishes itself from siblings like delete_task by describing the cascading removal of tasks, milestones, and dependencies. This makes the tool's purpose unambiguous and distinct.

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 deleting an entire project and its contents, but it does not explicitly compare with alternatives like delete_task or state when not to use it. The warning about permanent deletion and cascading effects provides some contextual guidance, but no explicit when/when-not guidance is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses a key behavioral trait: child tasks and dependencies are removed as well. This is essential for a destructive operation. It does not explicitly state irreversibility or permission requirements, but the cascade disclosure is significant.

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 one short, front-loaded sentence. It states the action and the most critical side effect without any 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 delete tool with one parameter and no output schema, the description covers the core action and the most important side effect. It does not discuss errors or return values, but these are not critical for a task of this simplicity.

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 0% and the description does not mention the taskId parameter at all. The parameter is simple and self-explanatory, but the description adds no meaning beyond the schema's name and type. It fails to compensate for the low 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 clearly states the action ('Delete a task') and identifies the resource (task). It differentiates from sibling tools like delete_project by explicitly mentioning the cascade removal of child tasks and dependencies, which is a defining characteristic.

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 clear context that this tool is for deleting tasks, and the cascade note serves as an implicit warning about when to use it (not when children/dependencies should be preserved). However, it does not explicitly name alternatives or state 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden, and it delivers: it discloses the CPM method, progress-aware duration, return fields, and detailed limitations (only FS dependencies, business days behavior, no holiday table, ignores segments, no resource calendars). It also documents the cyclic_dependency error case. This is comprehensive behavioral disclosure.

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 well-structured: purpose, method, return values, limitations, and error handling each get a sentence. No wasted words; every sentence adds essential information. Despite being longer than average, it earns its length through density of useful content.

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?

The tool has no output schema and no annotations, so the description must cover return values and edge cases. It does this thoroughly: lists returned fields, explains defaults and limitations, and describes the error response. For a computational tool with 3 params, this is fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description mentions business_days behavior and as_of_date, but these duplicate the schema descriptions. It adds no new parameter-level semantics beyond what the schema already provides, so the baseline holds.

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 calculates the critical path of a project and returns it as data. It uses a specific verb ('calculate') and resource ('critical path of a project'), and distinguishes itself from sibling CRUD/list tools by emphasizing it's an analysis tool that shouldn't be replaced by manual reasoning over task lists.

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 clear usage context: use this to get critical path data instead of reasoning over raw task lists. It does not explicitly name alternatives or state exclusions, but the purpose and limitations make when to use it obvious. The absence of an explicit 'when-not-to-use' prevents a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries responsibility for behavioral disclosure. It states the information returned but omits any note about read-only nature, error behavior, or authentication requirements, though 'get' implies a safe read 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?

The description is a single concise sentence that front-loads the verb and resource, with no superfluous words. It is admirably compact.

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 provides a basic overview but does not fully specify the return structure or tie it to usage context. It names two included fields but leaves 'detailed information' vague, so a score of 3 reflects the gap.

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 already documents taskId with a clear description (UUID), achieving 100% schema coverage. The description adds no additional parameter semantics, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Get' with resource 'single task' and details what information is included (assignees, dependencies), clearly distinguishing from sibling list_tasks or get_critical_path.

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 phrase 'single task' provides clear context that this tool is for retrieving one specific task, implying it should be used instead of list_tasks for detailed views. However, it does not explicitly mention alternatives or exclusions, so it earns a 4 rather than 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. The verb 'list' implies a read-only operation, which offers basic transparency, but it does not disclose return format, ordering, pagination, or error behavior. This is adequate for a simple lookup 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, well-structured sentence with no unnecessary words. It front-loads the action and resource, making it efficient and easy 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?

The tool is simple with one parameter and no output schema, so the description is nearly complete for selection purposes. However, it lacks information about what the response contains, which the absence of an output schema makes more critical.

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 contains one required parameter, projectId, with no description fields (0% coverage). The description references 'in a project', hinting that projectId identifies the project, but it doesn't explicitly explain the parameter's meaning or expected format. The parameter name is self-explanatory, compensating partially.

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 'List milestones in a project' with a specific verb and resource, and it distinguishes itself from sibling tools like list_tasks and list_projects by targeting milestones. Adding 'key dates such as launch or review gates' further clarifies what milestones are.

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 clear context: use this tool to list milestones within a project. It doesn't explicitly name alternatives or exclusions, but the purpose is evident and it is positioned appropriately among sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the behavioral burden. It discloses the 'excluding archived' filter, which is useful, but does not explicitly state that this is a read-only operation or describe any other side effects. The read-only nature is implied by 'list' but not stated.

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 front-loads the core purpose and includes a key filter. There is no redundancy or wasted information.

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 list tool with one parameter and no output schema, the description is adequate. It covers the primary behavior and filter, though it does not describe return values or formatting, which could be expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage for the workspaceId parameter with a description. The tool description adds no additional parameter information, so it relies on the schema, which is sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('List all projects') and the resource ('projects in a workspace'), with a specific filter ('excluding archived'). This distinguishes it from sibling tools like list_tasks and list_workspaces.

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 its usage for listing projects but does not explicitly mention when to use it over alternatives or any exclusions. The context is clear, but no explicit guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of behavioral disclosure. It does not explicitly state the operation is read-only, nor does it mention pagination, ordering, or error behavior. The only behavioral hint is the word 'List', which implies retrieval, but that is minimal.

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 front-loads the core purpose ('List tasks in a project') and then lists optional filters. 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?

The description covers the basic purpose and filters but lacks details about the return format, pagination, or potential errors. Without an output schema, the description could have added value by stating that it returns a list of task objects, but it does not. For a simple list tool, this is a moderate gap.

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 high (75%), with search, projectId, and assigneeId already described in the schema. The description adds no new parameter semantics beyond re-stating the filter names. Since the schema does the heavy lifting, baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists tasks within a project, using a specific verb ('List') and resource ('tasks'). It differentiates from sibling tools like get_task (single task retrieval) and list_projects (projects instead of 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?

The description implies usage for filtering tasks by name, status, or assignee, but provides no explicit guidance on when to use this tool versus alternatives. It does not mention that get_task should be used for a single task, nor any exclusions or prerequisites beyond the required projectId in the schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It adds a key behavioral detail—only workspaces the authenticated user is a member of are returned—which is valuable. However, it does not explicitly state read-only behavior, pagination, ordering, or return format, leaving some transparency gaps.

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 with no redundant information. It is concise and easy to parse, earning the highest score for structure.

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 zero-parameter tool with no output schema, the description adequately conveys the core purpose and scoping. It could be more complete by mentioning return fields or pagination, but the simplicity of the tool makes this a minor gap. Overall, it is mostly sufficient.

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 tool has zero parameters and an empty schema, so the description correctly focuses on the operation. With no parameters, baseline is 4, and the description adds value by clarifying the membership scope, which is not derivable from the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Get') and resource ('all workspaces the authenticated user is a member of'), providing specific scope. It distinguishes itself from sibling tools, which all focus on projects, tasks, or milestones rather than workspaces.

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 listing workspaces but provides no explicit when-to-use guidance or exclusions. With sibling tools like list_projects and list_tasks, the intended context is inferable, but the description does not directly state when this tool is preferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden and excels: it discloses default dry_run (no DB writes), commit mode with all-or-nothing transaction, forward-only cascading, pinned tasks (progress=100 plus additional), conflict recording and propagation stopping, and known v1 limitations. This is exceptional behavioral transparency.

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 dense but well-structured: first sentence states core purpose and mode, second explains propagation rules, third covers limitations. It is slightly long but every sentence contributes critical information for a complex tool. Front-loading the purpose and default behavior is effective.

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 7-parameter complexity, no output schema, and no annotations, the description is nearly complete. It covers modes, conflict handling, pinned tasks, and limitations. The only minor gap is a lack of explicit return-value description, but the commit/dry_run distinction implies what is returned. Referencing get_critical_path for limitations is efficient.

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 is 3. The description adds context about shift behavior (e.g., 'pushes only if predecessor's new end + lag would violate'), but most parameter semantics are already in the schema. The description repeats some schema details (mode, pins) without adding significant new meaning beyond behavioral context.

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 opens with a specific verb+resource: "Compute the downstream impact of shifting a single task." It clearly distinguishes itself from generic update tools by focusing on propagation and impact analysis. The title and sibling context further reinforce its specialized role.

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 context by explaining the dry-run default (for planning) and commit mode (for persistence), and by referencing get_critical_path for shared limitations. It does not explicitly name alternatives or state when not to use, but the clear purpose and mode semantics give sufficient guidance for an agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden of explaining side effects. It does so meaningfully by disclosing that status is auto-derived from the progress value (0=not_started, 1-99=in_progress, 100=done), which is a non-obvious behavioral consequence. It stops short of describing failure modes or update semantics, but the provided behavior is valuable and non-redundant.

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 states the action, the range, and the resulting behavior. Every clause earns its place, with no fluff or redundancy.

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?

This is a simple two-parameter tool with no output schema and no annotations. The description covers the core action, the input constraint (0-100), and the important auto-derived status side effect. It is mostly complete for an agent to use correctly, though it omits mention of return values or error cases—acceptable for this simplicity but not exhaustive.

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 provides only types and ranges with 0% description coverage, so the description must compensate. It explains the meaning of the 'progress' parameter, including its accepted range and how values map to statuses. The 'taskId' parameter is left to the schema and name, but it is self-evident enough that this is acceptable.

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 identifies the tool's action ('Update the progress percentage of a task') and specifies the exact resource and field being affected. This distinguishes it from the broader sibling update_task by focusing specifically on progress percentage, so an agent can select it unambiguously.

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—this is the tool to set progress—but does not explicitly contrast it with update_task or state when to prefer this over alternatives. The status auto-derivation note provides context on what happens after use, but there is no explicit 'use this when' or 'instead of' guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the key behavior that only provided fields are modified, which is valuable. However, with no annotations, it omits other important behavioral details such as error handling when the task does not exist, whether the updated task is returned, or any permission requirements. The burden is only partially met.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the main action, and every sentence adds value. It is concise and easy 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?

For a tool with 9 parameters, no output schema, and no annotations, the description is too sparse. It covers partial update but does not explain return values, failure modes, or when to prefer set_task_progress, leaving significant gaps for an agent to operate 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 description coverage is low at 33%, and the tool description does not compensate by explaining any parameters. It only generically says 'fields' without enumerating or clarifying them, leaving many parameters undocumented 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's action with a specific verb ('Update') and resource ('existing task'), and explicitly notes the partial-update behavior. This distinguishes it from siblings like create_task and delete_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 use when an existing task needs modification, but does not provide explicit guidance on when to use this tool versus the specialized sibling set_task_progress, nor any exclusions or prerequisites. Usage context is clear but not fully scoped.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.