clickup-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools target distinct resource-action pairs (e.g., create_space vs create_list vs create_folder are clearly different). A few potential overlaps exist: get_time_entries vs create_time_entry vs start_timer manage similar data, and get_task_watchers/add_task_watcher overlap with task membership. Overall boundaries are mostly clear.
Naming Consistency4/5
The vast majority follow a consistent verb_noun pattern (e.g., create_space, update_task, delete_comment, get_lists). Minor deviations exist: get_folderless_lists, get_filtered_team_tasks, and set_custom_field_value break the simple verb_noun form but are still readable and logical.
Tool Count2/5
97 tools is far too many for most agentic use cases, despite ClickUp's broad surface. The count exceeds the heavy threshold (25+) by a wide margin, and the score reflects that the surface is bloated even if ClickUp genuinely offers this many operations.
Completeness5/5
The coverage is remarkably comprehensive: full CRUD across workspaces, spaces, folders, lists, tasks, comments, time entries, goals, key results, checklists, tags, views, webhooks, guests, and custom fields. There are essentially no dead ends—everything from creation through deletion is covered.
Average 2.8/5 across 97 of 97 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. It does not reveal that this is a mutation (though implied by 'update'), nor does it describe partial-update semantics (whether omitted fields are preserved), idempotency, or validation behavior. For a state-changing tool with 15 parameters, this is a substantial transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence 'Update an existing task' is efficiently short with no waste. However, it is under-specified — this is not genuine conciseness but rather minimalism that sacrifices informational value. A sentence providing even a few key updatable fields would merit the same concision with better content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool with 15 parameters, 2 requiring explanation (assignees nested object, custom_item_id nullable), no annotations, no output schema, and only 13% schema description coverage. The description 'Update an existing task' is wholly inadequate for an agent to safely invoke this tool — it doesn't enumerate updatable fields, explain partial-update behavior, or clarify ambiguous parameters. This is in the lowest tier of completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13%, with only task_id and parent having descriptions in the schema. The description adds nothing about the parameters. However, some params are self-explanatory by type/name (name, status, description, archived, priority). The baseline is 3 given low coverage but meaningful type hints; notably the nested assignees object and fields like custom_item_id, time_estimate, and the date_time booleans get no semantic explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing task' uses a clear verb+resource but is a tautology of the tool name (update_task). It provides zero detail about what specific aspects can be updated — no mention of status, priority, assignees, dates, or any of the 15 parameters. It fails to distinguish from sibling tools like create_task, delete_task, move_task_to_list, or duplicate_task which all relate to task manipulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives. The description doesn't mention it can change parent (reparenting), move status, or reassign — and doesn't clarify distinctions from move_task_to_list (which moves between lists) or update_goal/update_key_result. No exclusions or when-not-to-use context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It is a mutation operation (adds a dependency) with potential side-effects, but the description does not disclose whether the operation is reversible, what happens to existing dependencies, whether dependencies are directional, or what the response looks like. For a write tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient at one sentence, but it is under-specified rather than concise. While there is no wasted text, the brevity does not earn its presence because it adds no information beyond what the name already conveys, so the conciseness is not a virtue here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and no annotations, the description does not explain the directionality semantics of depends_on versus dependency_of, whether both can be set simultaneously, error conditions, or the meaning/return of the operation. The parameter semantics of a bidirectional dependency relationship are genuinely ambiguous and the description fails to clarify them. There is no output schema to compensate for this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter descriptions (despite being minimal) do explain each field's meaning: task_id, depends_on, and dependency_of. However, the description adds nothing beyond the schema, and the relationship between depends_on and dependency_of (mutual exclusivity? required together?) is unclear from both the schema and description. The baseline 3 applies since schema covers parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Add a dependency between tasks" is a near-tautology of the tool name. It states the verb (add) and resource (task dependency) but provides no additional scope detail, such as how dependencies are represented (depends_on vs dependency_of) or what type of relationship is being created. It does not distinguish itself from the sibling delete_task_dependency beyond the obvious add/delete polarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., both tasks must exist, be in the same workspace), and no context about whether task dependencies require special permissions. The description provides no use-case context whatsoever beyond the bare operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Update' implies mutation, but there's no mention of whether partial updates are supported, whether omitting fields resets them, what happens to unspecified fields, permission requirements, or side effects on related entities like tasks or members. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse sentence with no waste, which is efficient. However, at 4 words it verges on under-specification rather than true conciseness — it saves words but fails to convey necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no annotations, no output schema, only 25% schema coverage, and 6 undocumented parameters, this description is severely incomplete. For a mutation tool of this complexity, the description should explain what fields do, the meaning of unset_status and due_date_time, behavior when fields are omitted, and interaction with due_date vs due_date_time. Despite sibling richness, the description provides no guidance on selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description must compensate. The description ('Update an existing list') adds zero parameter semantics. Notably, the schema itself lacks descriptions for 6 of 8 parameters (name, content, due_date, priority, unset_status, due_date_time have no descriptions), and the tool description doesn't clarify what these mean. The 'unset_status' and 'priority' semantics are especially unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Update' with the resource 'list', which is clear enough. However, it doesn't differentiate from siblings like update_task, update_folder, or update_space — all mutation tools on different resources. The description is minimal and generic, relying on the tool name for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There's no mention of which list types this applies to (folder lists vs folderless lists), or which fields are updatable in which contexts. The sibling set includes many list-related tools, but there's no exclusion or alternative naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden of behavioral disclosure. It doesn't state whether the link is bidirectional, whether existing links are overwritten or duplicated, whether linking requires permissions, or what happens if a cycle is created. For a mutating operation with zero annotation coverage, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste, front-loaded with the core purpose. However, extreme brevity here reads as under-specification rather than disciplined conciseness, since the tool needs more context for a correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, 50% param coverage, and only 2 of 4 params documented, the description leaves substantial unknowns. The agent cannot determine what response to expect, when team_id/custom_task_ids are required, or how this differs from dependency tools. Incomplete for a mutation tool with sibling ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, with task_id and links_to documented but team_id and custom_task_ids left undescribed. The description adds no parameter information beyond 'Link two tasks together'. It doesn't explain the roles of team_id or custom_task_ids, leaving the agent guessing about their purpose
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Link two tasks together' identifies a verb+resource action, clearly distinguishing it from siblings like remove_task_link and add_task_dependency. However, it doesn't clarify what linking means semantically (e.g., creating a relationship vs. dependency), leaving some ambiguity about whether this creates a simple relation or a dependency link.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like add_task_dependency, which likely overlaps in task-linking behavior. No when-to-use, prerequisites (e.g., team_id needed?), or exclusions are mentioned. The agent has no direction on choosing between link and dependency tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Post' implies a write/mutation operation, but nothing is stated about whether it requires specific permissions, whether comments appear immediately to all viewers, whether there's rate limiting, or what the response looks like. With zero annotation coverage, this is a significant gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero wasted words. However, it is under-specified rather than concisely complete; the brevity reflects missing information rather than distilled essentials.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-param mutation tool with no annotations, no output schema, and only 33% schema coverage, the description should compensate by explaining return values, the notify_all param's effect, and distinguishing from related comment tools. It does none of these. The two undocumented parameters and missing behavioral context make this incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (1 of 3 params documented: view_id). comment_text and notify_all are undocumented in the schema with no type-level descriptions, and the tool description adds nothing about them. The notify_all boolean is particularly ambiguous — the description gives no hint about what 'notify all' means or its default behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Post a comment to a Chat view" uses a specific verb (Post) and identifies the resource (a Chat view comment). However, it doesn't explicitly distinguish from siblings like create_task_comment, create_list_comment, or create_threaded_comment, though the phrase 'Chat view' does partially disambiguate. The purpose is understandable but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many sibling comment-creating tools (create_task_comment, create_list_comment, create_threaded_comment). The description implies it's for Chat-view comments but provides no context about when a Chat view comment is appropriate versus other comment types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden of behavioral disclosure. It does not mention that this creates a side-effect (adding a persistent comment), whether notify_all triggers notifications to members, whether assignee sets a commenter assignment, or any authorization requirements. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence, six words), which is concise, but it borders on under-specification rather than genuine conciseness. It earns a moderate score because there's no waste, but it's so minimal it adds minimal value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations and no output schema, and 3 of 4 parameters are undocumented. For a tool that should explain what happens when a comment is added, who gets notified, and how assignee works, the one-sentence description is inadequate. It should clarify the relationship to the notify_all and assignee fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only list_id has a description), so the description must compensate. It mentions nothing about comment_text, assignee, or notify_all semantics. The description 'Add a comment to a list' adds no information beyond what the tool name implies and does nothing to explain the four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a comment to a list' uses a clear verb ('Add') plus resource ('comment to a list'), which states the core purpose. However, it doesn't differentiate from sibling tools like create_task_comment, create_chat_view_comment, create_threaded_comment, or other comment-related tools, and fails to mention the assignee/notify_all capabilities it supports beyond simple commenting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the many sibling comment tools (create_task_comment, create_chat_view_comment, create_threaded_comment). The description does not specify that this targets list-level comments specifically, nor when to prefer it over alternatives. With numerous sibling comment tools present, this is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Permanently' hints at destructiveness but doesn't disclose what happens to the space's contents (tasks, folders, lists), whether there's any recovery mechanism, or any confirmation/authentication requirements. For a destructive delete operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. It's appropriately minimal for a straightforward action. However, at only 3 words, it borders on under-specification rather than genuine conciseness, but for a single-parameter delete tool it's reasonably sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a destructive mutation with no annotations and no output schema. The description should disclose the permanence implications, cascade effects on contained resources, and any error conditions. With one parameter at 100% schema coverage, the schema is handled, but the destructive nature of the operation is under-communicated despite the 'permanently' qualifier.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents space_id as 'The space ID'. The description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting and the single parameter is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a space permanently' clearly states the verb (delete) and resource (space), with the important qualifier 'permanently' signaling irreversibility. It distinguishes from sibling delete tools (delete_space_tag, delete_folder, delete_list) by naming the specific resource. However, it's quite minimal and doesn't elaborate beyond the basic action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, when NOT to use it, or alternatives. The description doesn't mention prerequisites (e.g., whether the space must be empty, or whether there's a soft-delete alternative). It doesn't distinguish when to use delete_space vs delete_folder or delete_list for cascading effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It doesn't disclose pagination behavior, ordering of returned comments, whether only top-level comments are returned, or any auth requirements. Given there are 3 parameters (start, start_id) suggesting pagination, the lack of behavioral detail on this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a retrieval tool with pagination parameters, undocumented sibling differentiation, no output schema, and no annotations, the description is too thin. It doesn't explain pagination semantics, comment ordering, the relationship between start/start_id, or how this differs from other comment-getting tools. Given the 3 parameters and complex sibling landscape, it should do substantially more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only view_id has a description). The description adds no param information at all, and the two pagination parameters (start, start_id) are completely undocumented. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb ('Get') and resource ('comments from a Chat view'), which is clear. However, it doesn't distinguish among the many sibling comment tools (get_task_comments, get_list_comments, get_threaded_comments), and 'Chat view' is ambiguous without context on what a Chat view is versus other view types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus sibling alternatives like get_task_comments, get_list_comments, or get_threaded_comments. No context is provided for when a Chat view exists or what differentiates it from other view types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Invite' implies a write/mutation operation, but nothing is said about whether this sends an email, requires the target to accept, is idempotent, what happens on duplicate invite, or what the return value is. For a mutating tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is extremely concise and has no wasted words. It's not verbose, but it's under-specified rather than elegantly concise—brevity here is a symptom of missing substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter mutation tool with no annotations, no output schema, and only 25% schema coverage, this description is far from complete. It doesn't clarify what the guest's default permissions are, how optional booleans interact, the role of custom_role_id, or anything about the invite outcome/response. The agent would be guessing on 6 of 8 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, meaning 6 of 8 parameters (can_edit_tags, custom_role_id, can_create_views, can_see_time_spent, can_see_time_estimated, can_see_points_estimated) are completely undocumented in the schema. The description offers zero compensation for these. It doesn't explain what these boolean permission flags govern, the meaning of custom_role_id, or the relationship between the optional booleans and that role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Invite a guest user to a workspace' uses a clear verb (invite) and resource (guest user to workspace). It distinguishes reasonably from sibling 'remove_guest_from_workspace'/'get_guest' by the action verb, though it doesn't specify any nuance beyond that basic action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. There's no mention of permission requirements, whether the invited guest must already exist, email domains, or how the guest flow relates to get_guest or remove_guest_from_workspace. The description provides no context for selecting this among the 100+ siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't state whether starting a timer affects an existing running timer (does it stop/overwrite?), whether it requires active workspace context, or what happens on success. The term 'running timer' suggests there may be an existing timer involved, but the exact behavior (start one vs. resume one) is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief at a single clause, which is concise in length, but it's under-specification rather than efficient communication. The phrase 'a running timer' is awkward and could have been used better to convey behavior. There is no room for waste, but also no content that adds depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, no annotations, and a low schema description coverage (20%), the description should provide substantive context. It provides almost none - no mention of return values (none specified), no parameter semantics, no behavior details. For a state-changing timer tool among many related time tools (create_time_entry, update_time_entry, stop_timer, get_running_timer), this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only team_id is described as 'The workspace/team ID'). The description adds nothing about the four undocumented parameters: task_id, description, billable, and tags. Given the low coverage, the description should compensate by explaining key parameter relationships (e.g., how task_id ties to the target task, or what billable affects), but it remains silent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start a running timer on a task' uses a clear verb+resource structure and identifies the target (a task). However, the phrasing is odd ('Start a running timer' is slightly tautological/confusing - a timer that is already running?). It distinguishes the core action from sibling get_running_timer and stop_timer, but doesn't specify what 'running' means in the context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description doesn't say when to use this tool versus create_time_entry, update_time_entry, or stop_timer - sibling tools that could be confused for timer management. There's no mention of prerequisites (e.g., whether a timer must already exist or the task must be valid) or whether this starts a new timer when none exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It doesn't state whether this is a safe read-like operation or a mutating one (though the verb implies mutation), whether partial updates are allowed, what happens to existing tag color when only name is provided, or any permission requirements. The description adds minimal behavioral context beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It's front-loaded and immediately clear on the core action. However, it's so concise that it omits necessary behavioral and parameter guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no output schema, and 60% parameter coverage. The description does not explain the rename semantics (tag_name identifier vs new name), color handling, or any edge cases. For a mutation affecting state, this description is insufficiently complete, especially given the 5-parameter surface.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%: name and space_id and tag_name have descriptions, but tag_bg and tag_fg lack any description. The description itself adds nothing about parameters beyond the schema. The tool description does not explain that tag_name is the current/identifying tag while name is the new value, which is a critical distinction for an agent to invoke it correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb (Update) and the resource (a tag in a space), which clearly identifies the core action. However, it lacks detail on what aspects of a tag can be updated (name, colors), and there is no distinction made from siblings like create_space_tag or delete_space_tag, though those differ by verb naturally.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus create_space_tag, delete_space_tag, or get_space_tags. The description gives no context about prerequisites (e.g., tag must already exist in the space), no exclusion criteria, and no mention of the relationship between tag_name and name parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states what it does, not how it behaves: it doesn't state that a running timer may continue if stop is omitted, whether this can conflict with existing running timers, whether permissions beyond team membership are needed, or whether the `assignee` parameter lets one agent log time for another user. The schema hints at running-timer behavior via the stop parameter description, but the tool description itself is silent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence ('Log a time entry for a task'), which is concise. However, it is under-specified—there is no structure, no prerequisites, no team/workspace context, and no mention of the required team_id parameter or how this create operation relates to the broader timer lifecycle. Brevity alone isn't conciseness when meaningful info is absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with 9 parameters, no annotations, and no output schema. The description provides essentially no information beyond the tool's name. For an API that exposes start_timer, stop_timer, get_running_timer, and update_time_entry as siblings, the description should clarify open-timer semantics, timer conflicts, and whether multiple entries can be open simultaneously. The description is inadequate for the complexity of this tool's domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 78% (7 of 9 params have descriptions in the schema), so the schema carries most of the parameter documentation load. The description itself adds no parameter information. The core relationship—that start is required and stop vs duration are alternatives—is encoded in the schema but not explained in the description. Given the decent schema coverage, a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Log a time entry for a task' uses a clear verb+resource, establishing it as a write operation to create time entries. However, it doesn't distinguish itself from siblings like start_timer, stop_timer, or update_time_entry, which are related but serve different lifecycle purposes. The scope is understood but the tool-to-task relationship could be clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use create_time_entry versus start_timer, update_time_entry, or stop_timer. The sibling set includes many timer-related tools, and the description provides no context on when a logged entry would be preferred over starting a running timer, nor excludes scenarios. The schema notes about running timers are the only implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description says 'Update' implying mutation, but doesn't state whether partial updates are allowed, whether unspecified fields are left unchanged, what permissions are required, or how the private/archived flags behave when toggled. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with zero waste, which is structurally efficient. However, it's under-specified rather than concisely comprehensive—it's so terse that it borders on being a tautology of the tool name. It earns credit for brevity but lacks the informational content that would justify a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 7-parameter mutation tool with no annotations, no output schema, and only 14% schema description coverage. The description must compensate for all of this but does not. It doesn't explain which fields are updatable, whether partial updates are supported, what the response returns, or any side effects. The tool is substantially under-documented for a complex update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only space_id has a description), so the description should compensate. However, the description provides zero parameter information. The score is baseline 3 because the 6 undocumented parameters (name, color, private, archived, admin_can_manage, multiple_assignees) have self-explanatory names, but the description adds nothing about their semantics, format, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing space' names the verb 'Update' and resource 'space', which gives a clear basic purpose. However, it doesn't specify which fields or attributes can be updated, nor does it differentiate this from the many sibling get_/create_/delete_ operations on spaces. It's clear but minimal, not distinguishing it from related space operations like create_space or delete_space.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context about when updating is appropriate (e.g., modifying settings vs. creating a new space vs. deleting), no prerequisites mentioned, and no exclusions stated. With 94 sibling tools including create_space and delete_space, a note about the appropriate use case would be valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The word 'update' implies mutation, but the description doesn't state what happens to existing timer values (e.g., does updating 'start' or 'end' recalculate duration?), whether the timer must be stopped first, whether partial updates are supported, or what the response contains. For a mutation tool with zero annotation coverage, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (4 words: 'Update a time entry'), which is technically concise but under-specified rather than genuinely economical. It lacks structure because there's essentially nothing to structure. A slightly longer description explaining update semantics and key parameters would earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter mutation tool with no output schema and minimal annotation coverage, the description is inadequate. It should explain update semantics, behavior around partial updates, the tag_action enum, and timer-related constraints. The schema documents only 20% of parameters, so the description needs to compensate but provides zero additional context. This is significantly incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only team_id and timer_id are described). The description adds no parameter-level detail beyond what the schema provides. The tool has 10 parameters, including nuanced ones like tag_action (replace vs add), billable, and duration, none of which are explained in the description. However, the schema does include some inline descriptions for the two required fields, providing baseline coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Update a time entry" uses a clear verb+resource pattern and correctly identifies the mutation operation. However, it doesn't distinguish this from sibling mutation tools like create_time_entry, and it doesn't specify which fields can be updated or whether updating differs from creating in scope. The purpose is adequate but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With 10 sibling time-related tools (create_time_entry, delete_time_entry, start_timer, stop_timer, get_time_entry), the description offers no differentiation or context for when an agent should choose update_time_entry over these. Notably, it doesn't clarify the relationship to timers (e.g., updating vs stopping a running timer).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't state whether this mutates data (clearly it adds/modifies), whether it errors if the tag doesn't exist, whether duplicate tags are rejected, or what the response format looks like. For a mutation tool with zero annotation coverage, this is a meaningful transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with zero wasted words. It's appropriately compact for a simple tool. Not a 5 because it omits useful behavioral detail that could be woven into the same concise format, but structurally it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-param mutation tool this is somewhat minimal but acceptable. However, given the zero annotation coverage and the ambiguity around whether tags must pre-exist (especially with create_space_tag and get_space_tags as siblings), the description should clarify the relationship between this tool and tag lifecycle. There's no output schema to compensate for the missing behavioral detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% — both task_id and tag_name are documented with simple descriptions ('The task ID', 'Tag name to add'). The description doesn't add meaningful semantics beyond what the schema provides, so the schema does the heavy lifting. Baseline 3 is appropriate; neither parameter needs elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a tag to a task' states the verb and resource clearly, and it distinguishes from the sister tool remove_tag_from_task. However, it could be more specific about what 'adding a tag' entails (e.g., whether it creates the tag if it doesn't exist, or whether it applies an existing tag) — this lack of behavioral specificity keeps it from a higher score despite being a clear basic purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. With siblings like create_space_tag, get_space_tags, and remove_tag_from_task, the description provides no context on prerequisites (e.g., must the tag already exist in the space?) or when to prefer this over creating then assigning a tag. Implied usage only — adding a tag to a task — but no when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description is purely performative ('Add a watcher to a task') with no explanation of side effects, whether permissions are needed, whether the watcher is notified, whether duplicate watchers are rejected, or what happens on failure. For a mutating tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single short sentence, efficiently stated with no wasted words. However, the conciseness is achieved through under-specification rather than careful triage, and the tool name and description are near-duplicates of each other.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating two-parameter tool with no annotations and no output schema, the description should provide more context such as notification behavior, error conditions, or relationship to remove_task_watcher. The minimal one-line description is inadequate for the tool's complexity and leaves the agent without behavioral guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents both parameters (task_id as 'The task ID' and watcher_id as 'User ID to add as watcher'). The description adds no additional meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Add a watcher to a task' with a specific verb and resource. It is clear about the action but does not distinguish from siblings like remove_task_watcher or add_tag_to_task, though the resource and action are distinct enough that confusion is unlikely. It's functional but minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites (whether the task must exist, whether the user must be a workspace member), no exclusions, and no indication of how this differs from add_tag_to_task or other add operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided (neither readOnlyHint nor destructiveHint), so the description carries the full burden of behavioral disclosure. 'Create' implies a mutative write operation, but the description doesn't disclose whether it overwrites existing goals, whether it requires specific permissions, what happens on duplicate names, or how the response is structured. For a creation tool with zero annotation coverage, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no waste. It's appropriately front-loaded with the core action. However, it's so minimal that it borders on under-specification rather than deliberate conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a creation tool with 7 parameters, no annotations, no output schema, and no param-level documentation in the description. The complexity (owners as array, color, due_date in Unix ms, multiple_owners flag) deserves more behavioral and contextual explanation. The description leaves significant room for agent confusion about required vs optional semantics and creation side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71% (5 of 7 parameters have descriptions). The description adds no parameter-level information beyond the schema. The description adds zero meaning beyond what the input schema provides. The uncovered parameters (description, multiple_owners at 29%) are not addressed in the description. Baseline 3 is appropriate since schema does most of the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new goal in a workspace' has a specific verb+resource (create a goal) and identifies the scope (workspace). However, it doesn't distinguish this from sibling tools like create_key_result or update_goal. The purpose is clear but generic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention relationships to goals (e.g., that goals live under a workspace, that key_results are associated with goals), nor any context about prerequisites like requiring team_id or that multiple_owners flag exists. There's no when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states a mutation ('create') but does not disclose what the response returns, whether the operation has side effects (e.g., notifications), permission requirements, or how errors manifest. For a state-changing tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is efficient and front-loaded with the core purpose. No filler or redundancy. It earns its place but is arguably too terse given the missing usage and behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 7-parameter creation tool with no annotations and no output schema. The description covers only the essential purpose. It fails to address the folder-vs-folderless distinction, potential required field interactions (e.g., status matching a space status), and what the successful call returns. For a tool with this complexity, it should provide more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 7 parameters with descriptive text (e.g., priority value meanings, due date units). The description itself adds nothing about parameters; baseline 3 applies since the schema handles the documentation burden adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new list in a folder' states a clear verb+resource ('create'+'list') and identifies the containing location (folder). It does not, however, distinguish this from the sibling create_folderless_list, which creates a list without a folder — a meaningful distinction the description omits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs create_folderless_list, which is its most direct alternative. The description gives no context about when a list belongs in a folder vs. folderless, and doesn't mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Reply to an existing comment' implies mutation but doesn't disclose behavioral traits: whether comment_text has length limits, whether notify_all requires specific permissions, what happens if comment_id is invalid, or the return format. For a write operation with zero annotation coverage, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
'Reply to an existing comment' is a single efficient sentence with zero waste. It's appropriately brief, though given the low schema coverage and missing annotations, the brevity veers toward under-specification rather than true conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and only 33% schema coverage, this tool needs the description to carry more weight. The description doesn't cover parameter semantics for 2 of 3 params, doesn't clarify the notify_all behavior, doesn't mention permissions or error conditions. For a write operation with these gaps, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only comment_id is described). The description adds 'Reply' framing which clarifies that comment_id is the parent and comment_text is the reply content, but doesn't describe comment_text or notify_all semantics beyond what's in the schema. With low coverage, the description should compensate more but provides only marginal added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Reply to an existing comment' which clearly identifies the verb (reply) and resource (comment), distinguishing it from create_task_comment or create_list_comment which create standalone comments. However, 'threaded' differentiates it from perhaps create_task_comment, though the description doesn't explicitly leverage that distinction. The purpose is clear enough but doesn't explicitly reference the parent-child relationship aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives. There are multiple comment-creation siblings (create_task_comment, create_list_comment, create_chat_view_comment) and the description doesn't explain that this one is for replying within a thread while others create top-level comments. The parent comment_id requirement is implicit in the schema but not articulated as a usage cue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't mention whether the deletion is permanent/hard-delete, whether it can be undone, whether permission/ownership is required, cascading effects (e.g., on thread responses), or what happens to the comment data. For a destructive operation, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with zero waste—'Delete a comment'. However, being this terse borders on under-specification rather than genuine conciseness, since the description omits valuable behavioral and contextual information that would aid the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation tool with no annotations, no output schema, and minimal description. For a delete operation, the description should clarify at least permanent vs. soft delete, permission requirements, and return behavior. The single-sentence description is inadequate given the tool's potential to cause irreversible data loss.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter comment_id is the only parameter, and schema coverage is 100% with the schema describing it as 'The comment ID'. The description adds nothing beyond the schema—it doesn't clarify the format of the ID (UUID, numeric, etc.) or how to obtain it (e.g., from get_task_comments). With only one parameter at 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a comment', which clearly expresses the verb ('delete') and resource ('comment'). However, it doesn't distinguish from sibling tools like delete_task, delete_list, delete_time_entry, or update_comment. The purpose is functional but minimal, providing no scope, context, or differentiation from other deletion tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., needing comment ownership or permission), no explicit when-to-use/when-not-to-use guidance, and no reference to sibling tools like delete_task_comment or delete_list_comment. The usage context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. 'Delete a task permanently' signals mutation and irreversibility, but doesn't disclose what happens to related data (comments, attachments, watchers, dependencies), whether the operation requires specific permissions, or whether any confirmation or guard is in place. For a destructive operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (5 words), which is concise but borders on under-specification for a destructive tool with parameters. A single sentence with no wasted words earns credit for brevity, but the brevity comes at the cost of omitting essential behavioral and usage context. It's not 'efficiently sized'—it's barely specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no output schema, no annotations, and two undocumented parameters (team_id, custom_task_ids), the description is inadequate. It should explain the optional parameters' purpose (e.g., custom_task_ids may be required for teams using custom IDs), warn about cascading effects/irreversibility, and note any permission requirements. The current description leaves the agent to guess at significant operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only task_id is documented in the schema). The description adds no parameter information whatsoever. The parameters team_id and custom_task_ids are undocumented in both the schema and the description. Given the low coverage and no compensating description, the description fails to help an agent understand how to construct a correct, complete call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a task permanently' clearly states a specific verb (delete) and resource (task) with the important qualifier 'permanently' indicating irreversibility. This distinguishes it from sibling tools like delete_task_dependency and delete_task_link, which delete related entities rather than the task itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives like update_task, duplicate_task, or move_task_to_list. There's no mention of prerequisites (e.g., task must exist, permissions required), nor any warning about when NOT to use it (e.g., when you only want to archive or move a task). The 'permanently' qualifier implies finality but doesn't explicitly state when this is the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The description only states the action without revealing what happens to related data, whether the operation is reversible, what the effect is on task scheduling/critical paths, or how the directionality of the dependency removal works. For a mutation tool with zero annotation coverage, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. This is appropriately concise—though concise to the point of underspecification, the structural economy itself is admirable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 3 parameters (one required), no output schema, and no annotations. The description is a single sentence that fails to explain the directional semantics of dependencies, the meaning of two of the three parameters, or what the expected return value is. For a mutation tool with this complexity, the description is significantly under-equipped to guide correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% with 3 total parameters, so the description must compensate. Only task_id is documented in the schema ('The task ID'), while depends_on and dependency_of have no schema descriptions and no explanation in the tool description. The key semantic ambiguity—whether the dependency is incoming or outgoing—is entirely unresolved, making it impossible to correctly invoke this tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a dependency between tasks' uses a clear verb+resource construction that states the core purpose. However, it doesn't explain the directionality of dependencies (which task depends on which), which is the main ambiguity here given the depends_on and dependency_of parameters. It doesn't distinguish itself from the sibling add_task_dependency beyond being the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, and critically, there's no explanation of the semantic difference between depends_on and dependency_of. The agent can't determine whether to remove a dependency where this task depends on another, or where another depends on this task. No context about prerequisites or when dependency removal is appropriate is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided (no readOnlyHint, no destructiveHint), so the description carries the full burden of disclosing behavior. 'Duplicate' implies a copy operation, but the description doesn't clarify whether the original is preserved, whether the original task is removed, or whether any fail-grace operations exist. With zero annotation coverage, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero wasted words. However, it's under-specified—brevity here borders on being too terse rather than effectively concise, though it does front-load the core action clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description should explain more—what gets created, what happens to the original, what fields are carried over, and required permissions. The description provides only the bare minimum and leaves significant ambiguity about the tool's actual behavior, especially given that 'duplicate' semantics can vary widely between implementations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (task_id and list_id) are documented in the schema. The description adds minimal value beyond the schema—it does not explain the relationship between task_id and list_id beyond what the schema states. Baseline 3 is appropriate since the schema carries the documentation load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Duplicate a task into a list' clearly states the verb (duplicate), resource (task), and destination (list). However, it's minimal and doesn't distinguish itself well from siblings like move_task_to_list or create_task. The name itself already conveys most of the meaning, so the description adds little.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There's no mention of behavior nuances such as whether subtasks, checklists, or dependencies are duplicated, or whether this is preferred over create_task or move_task_to_list. The sibling tool 'move_task_to_list' is a natural alternative but is never referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a non-mutating read, but there is no mention of whether 404 or an error is returned for invalid folder IDs, whether access requires workspace membership, or what the response structure looks like. For a simple retrieval tool with zero annotation coverage, this is a minimal-but-adequate disclosure that stops short of helpful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is appropriately concise with zero waste. It front-loads the verb immediately. It could arguably be too terse, but for a simple single-parameter read tool, this level of conciseness is reasonable — being verbose would not add proportional value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool with 100% schema coverage and no output schema, the description is minimally viable but leaves gaps. It doesn't explain what fields the folder details contain, how errors are handled, or clarify the relationship to get_folders. The tool is low-complexity, so the completion burden is moderate, but the description could still specify the return content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the only parameter, folder_id, is documented as 'The folder ID'. The description adds no additional meaning beyond what the schema already provides. Baseline 3 is appropriate since the schema fully covers the parameter meaning and there's only one simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific folder' clearly uses an imperative verb with a resource, indicating a read operation. However, it doesn't specify what 'details' includes (e.g., name, lists, visibility settings) nor does it distinguish from closely related siblings like get_folders, get_folder_views, or get_folderless_lists. The purpose is discernible but lacks specificity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. With siblings like get_folders (listing all folders), get_folder_views, and get_lists, an agent needs to know this tool is for retrieving a singular folder's metadata by ID. There's no when-to-use, no exclusions, and no mention that folder_id is required to target a specific folder.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't mention pagination, ordering, whether archived folders are excluded by default, response format, or authentication/authorization requirements. The archived parameter hints that archived items are excluded by default, but this is only implied, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence - highly efficient with zero wasted words. It front-loads the action and resource clearly. Not verbose, though it could arguably trade some conciseness for more behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a list-retrieval tool with no annotations and no output schema. Given that it returns potentially many items, the description should disclose response shape, default filtering (archived excluded), ordering, and pagination. With just 6 words, it leaves the agent guessing about several critical behaviors beyond what the schema reveals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (space_id, archived). The description adds no meaning beyond the schema - it doesn't explain the relationship between the archived flag and default behavior, nor any format requirements for space_id. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Get all folders in a space'), which identifies what the tool retrieves. However, it doesn't distinguish from sibling tools like get_folder (singular, likely fetching a single folder), get_folderless_lists, or get_lists - the scoping is somewhat vague regarding whether this includes nested items or follows the space hierarchy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives. With many sibling folder/list/space retrieval tools, an agent cannot tell whether get_folders is the right choice over get_folder, get_folder_views, or other list-level tools. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description states what it does but provides no context on read-only behavior, authentication requirements, whether the goal must belong to a specific workspace, or what happens if the goal_id is invalid. For a read operation with zero annotation coverage, more transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. It states the purpose clearly without padding. It's concise to a fault, however - the brevity comes at the cost of missing valuable usage and behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a single-parameter tool, the description is minimal. Given this is a simple read tool, it doesn't require extensive documentation, but detail about what 'details' includes, whether it returns key results or just the goal itself, and the relationship to get_goals would strengthen completeness. The description is passable but leaves meaningful ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with 'goal_id' documented as 'The goal ID'. The description itself adds no information about the parameter beyond this. With full schema coverage, baseline 3 is appropriate since the schema already handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific goal' uses a clear verb+resource pattern and correctly identifies the tool as retrieving a goal's details. However, it doesn't describe what 'details' entails or how it differs from the get_goals sibling which likely retrieves all goals. The purpose is understandable but lacks specificity about the scope of details returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs the sibling get_goals or how it relates to other goal tools. The distinction between retrieving a single goal (this tool) versus a list of goals (get_goals) is implied by naming conventions but never stated explicitly. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It only states the tool retrieves goals but doesn't disclose whether completed goals are included by default, whether it returns paginated results, what the response structure looks like, or any auth/visibility requirements. For a read-only retrieval tool with no annotation coverage, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with zero waste. However, it's concise to the point of under-specification — the description would benefit from one more sentence covering include_completed behavior or response scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and no mention of return values, pagination, filtering by completed status, or which goal fields are returned. For a list-style tool, the description leaves significant gaps about what the agent can expect in the response and how to interpret the include_completed parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, with team_id already documented in the schema as 'The workspace/team ID'. The description adds minimal semantic value for parameters, but the include_completed boolean is undocumented in both schema and description. The description's 'all goals' phrasing suggests include_completed might be relevant but doesn't explain its default or effect. Baseline 3 for near-mid coverage but description adds little beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all goals for a workspace' states a clear verb+resource (get goals) with a scope qualifier (workspace). It adds the 'all' qualifier which distinguishes it from get_goal (singular). However, it doesn't clarify whether include_completed is included by default or what the scope means relative to spaces/folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives. There's a sibling get_goal (singular) and get_filtered_team_tasks, but no mention of when to choose this tool. The workspace scope is implied by the name and team_id parameter but never explicitly contrasted with space-level goal retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The get_ prefix implies a read operation, but the description doesn't state what details are returned, which list fields to expect, whether the list must exist (error handling), or scoping constraints. For a read tool with zero annotation coverage, more behavioral 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. It's appropriately concise for a simple single-parameter read tool, though it could benefit from a brief note on what details are returned without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with 100% schema coverage, the description is minimally adequate. However, with no annotations and no output schema, the description should clarify what 'details' means - which list attributes the caller can expect. Among many sibling list/get tool combinations (get_lists, get_list_views, get_list_members, get_list_comments), more context on what specifically this returns (the list's own properties vs related data) would complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (list_id), which is fully documented as 'The list ID'. The description adds some value by indicating the parameter identifies which list to fetch, but the tool name 'get_list' combined with the schema already makes this relationship fairly evident. Baseline 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get details of a specific list' which provides a verb+resource purpose. However, it doesn't distinguish from siblings like get_lists, get_folderless_lists, get_list_views, or get_list_comments - all sibling tools that also relate to 'lists' but serve different purposes. The agent must infer from the name alone that get_list retrieves a single specific list by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. The description gives no context about when to choose get_list over get_lists or get_folderless_lists, nor does it specify exclusions or prerequisites. Sibling tools like get_lists and get_folderless_lists exist with clearly overlapping concepts, yet no differentiation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't mention whether views include all types (custom views, default views), whether the result is paginated, ordering, depth of view objects returned, or any rate-limit/auth considerations. For a retrieval tool with zero annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence with zero wasted words. Front-loaded with the verb and resource. Appropriate length for a simple single-parameter retrieval tool. Not an under-specification issue, simply concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple 1-param retrieval tool with no output schema. The description is minimal but the tool itself is straightforward. However, given the large number of sibling view tools (workspace/space/folder/list/view), the description could better clarify the scope hierarchy and what 'views' means in this context to aid correct selection and usage. Slightly under-specified for its sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the single parameter list_id is described as 'The list ID'. The description itself adds no parameter information beyond the schema. Per the rubric, high schema coverage grants a baseline of 3, and there's some implicit meaning that the list_id selects which list's views to retrieve. Adequate but not enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Get all views for a list' uses a clear verb (Get) and resource (views) with scope (list). However, among siblings there are get_workspace_views, get_space_views, get_folder_views, and get_view, so it's reasonably distinct as a list-scoped variant but doesn't explicitly clarify whether these are list view configurations vs data views. Purpose is clear but minimally differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs the many sibling view tools (get_workspace_views, get_space_views, get_folder_views, get_view, get_view_tasks). No mention of what a 'view' means here or how it differs from get_view. Since there are multiple view-scoped siblings, the lack of differentiation guidance is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It doesn't mention any behavioral aspects: whether the task is read-only (though implied), what happens with custom_task_ids, whether subtasks require auth/team context, or what a 404 returns. For a read tool with no annotations, it should state the read-only nature explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste, front-loaded with the purpose. Brief and to the point. Could arguably lose nothing, though it could add value with a sibling note without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what 'details' means--what fields/objects are returned. The include_subtasks parameter is entirely undocumented. For a tool with 4 parameters and no output schema, this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (3 of 4 params have descriptions). The parameter schema adequately describes task_id, team_id, and custom_task_ids. The include_subtasks param has no description, so 25% is a gap. The description adds nothing beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific task' uses a clear verb+resource format. However, it does not distinguish itself from the many sibling tools like get_tasks (plural) or get_task_watchers/get_task_members/get_task_comments which are more specific. The 'details' term is vague about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It doesn't differentiate from get_tasks (which lists tasks), doesn't mention when custom_task_ids applies, and provides no context about when include_subtasks should be used. The sibling tool get_tasks exists but no exclusion is stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description conveys read-only intent ('Get') but does not explain behavior on missing IDs, error responses, or whether time entries have any special scoping rules tied to the team_id that the caller should be aware of. For a single-record fetch, there's minimal disclosure, though the read nature is at least implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with zero waste. It's appropriately minimal for a simple single-record retrieval tool, though it could benefit from adding sibling differentiation without much extra length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a very simple tool (2 well-documented params, no output schema, no nested objects), so the completeness bar is low. The description fully covers the purpose. However, the lack of any usage distinction from its sibling retrieval tools (get_time_entries, get_running_timer) leaves a gap in contextual completeness for an agent trying to select the right tool among a large sibling set of 100+ tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both team_id and timer_id are documented in the schema. The description adds no additional parameter meaning, but since the schema fully covers both parameters with clear descriptions, the baseline of 3 applies as documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single time entry' uses a specific verb and resource, clearly indicating it retrieves one time entry by ID. However, it does not distinguish itself from sibling tools like get_time_entries (list) or get_running_timer, leaving ambiguity about the precise scope and how it differs from related retrieval operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_time_entries or get_running_timer. The description gives no context on filtering, prerequisites (e.g., needing to know the timer_id in advance), or scenarios where this tool is preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It's a read operation (implying safety), but nothing is said about pagination behavior, whether relationships/filtering are applied, how many tasks can be returned, or whether viewing permissions gate the results. For a data-retrieval tool with zero annotation coverage, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no fluff. It's brief and front-loaded. However, the brevity comes at the cost of behavioral context; given the low information content, the conciseness reflects under-specification more than careful editing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a pagination parameter (page) and requires a view_id, but the description doesn't clarify pagination semantics (0-indexed is in the schema, but the relationship between pages and result ordering isn't explained). No output schema exists to describe the return shape. For a tool with two parameters and no behavioral notes, the description should compensate more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — both view_id and page have descriptive text in the schema. The description adds minimal value beyond the schema since it just restates that it gets tasks in a view, which maps to the view_id parameter. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get tasks visible in a specific view' uses a specific verb+resource (get tasks in a view). However, it doesn't differentiate from siblings like get_tasks, get_filtered_team_tasks, or get_view. The purpose is clear but there's no scoping distinction that would help an agent decide between this and other task-listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. With many sibling tools (get_tasks, get_filtered_team_tasks, get_chat_view_comments), the description gives no indication of when this tool is preferred over alternatives. The reference to 'a specific view' implies it requires a view_id, but doesn't clarify the relationship to get_view or get_workspace_views.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. It doesn't state whether this is a partial update, what side effects occur, whether authorization is required, or whether updating a goal cascades to key results. For a mutation tool with zero annotations, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero fluff. It's concise but borderline under-specified rather than poorly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 7 parameters, no annotations, and no output schema, this description is inadequate. It doesn't explain partial-update semantics, whether due_date accepts a timestamp, color format expectations, or how add_owners/rem_owners interact if both are provided. The tool carries meaningful complexity that the description fails to address.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 43% (3 of 7 params documented: goal_id, add_owners, rem_owners). The description adds no parameter information at all. The description doesn't compensate for the 4 undocumented params (name, color, due_date, description), though these are fairly self-explanatory by name. The add_owners/rem_owners distinction is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing goal' uses a clear verb+resource construction. However, it doesn't distinguish itself from siblings like update_task, update_comment, or update_key_result — though these are clearly distinct resources. The purpose is adequate but minimal, not specifying scope or what fields can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives, no prerequisites mentioned, and no caveats about required fields or partial updates. An agent has no indication whether omitted fields are preserved or reset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. 'Update' implies mutation but nothing is disclosed about whether changes are reversible, whether there are cascading effects on goals, or what the response looks like. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero filler, but arguably under-specified rather than concise. The sentence is efficient but lacks the contextual detail needed for a reliable update tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Moderate complexity tool with 3 params, no output schema, and no annotations. The description minimally covers what fields can be updated but fails to explain progress semantics, whether updates require specific permissions, or how partial updates behave. Adequate but with clear gaps for an update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage of the three parameters, giving a baseline of 3. However, the description adds little beyond the schema: it mentions 'progress or details' which loosely maps to steps_current and note, but doesn't clarify whether steps_current can be a target or incrementally updated, nor what format note should take. The description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a key result's progress or details' clearly states the verb (update) and resource (key result) with a specific scope (progress or details). It distinguishes from create_key_result and delete_key_result siblings, though it doesn't enumerate what 'details' encompasses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There are related goal/key-result tools (create_goal, update_goal, create_key_result, delete_key_result) but no mention of when updating a key result vs updating a goal is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description states 'adds a checklist' (a create/mutation operation) but discloses nothing about what task_state or existing checklist constraints might apply, how it interacts with existing checklists on the task, or what the response returns. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero wasted words. It's efficient, though arguably under-specified rather than appropriately concise. Given the brevity, 4 is fair — it avoids bloat but may be too thin to be genuinely helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create/mutation tool with no annotations, no output schema, 4 parameters and only 50% schema coverage, the single-line description is inadequate. It doesn't clarify whether checklists can have duplicate names on the same task, whether creation requires specific permissions, what happens if a checklist with the same name exists, or the semantics of team_id and custom_task_ids. This is a significant completeness gap for an operation that mutates task state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% — two of four parameters (team_id, custom_task_ids) have no description in the schema, and the description says nothing about them either. The description merely restates 'checklist' which maps to the name parameter, and the task is obvious from task_id. It does not clarify what team_id or custom_task_ids mean or when they're required. The description does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a checklist to a task' uses a specific verb+resource pattern and clearly states the target (task) and object (checklist). It's clear and distinct from siblings like update_checklist and delete_checklist, though it doesn't explicitly state scope or exclusions. It's understandable but very brief.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There's no mention of alternatives like create_checklist_item, no mention of whether checklist items are added separately after creation, and no indication of required task access or workspace context. The agent gets no situational guidance beyond the obvious purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Add an item to a checklist' reveals nothing about whether this is auditable, what happens on duplicate names, whether assignee is optional/required in practice, or any side effects. For a mutating tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence with zero waste. It directly states the action. Under-specification isn't penalized here as conciseness itself is tight and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no output schema, and no behavioral detail. For a basic add operation the description is minimal but not catastrophic; however, given zero annotation coverage and the absence of any guidance on assignee semantics or return behavior, more context would be valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters (name, assignee, checklist_id) are documented in the schema. The description adds nothing beyond 'Add an item', but per the baseline rule, when schema coverage is high, a 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add an item to a checklist' uses a specific verb+resource structure and is clear. However, among many sibling checklist/list/comment tools, it doesn't explicitly differentiate itself from similar 'add/create' operations beyond the obvious 'item' vs 'checklist' distinction, which is fairly implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives like create_checklist_item vs update_checklist_item, or how it relates to create_task/creating items in other contexts. There is no mention of prerequisites (e.g., that the checklist must be created first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the operation requires specific permissions, whether creating a folder is reversible, what happens on existing names or duplicates, or what feedback (return value) is given to confirm success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. It's concise but borders on under-specification; however, given the simplicity of the tool and the 100% schema coverage, this is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema, no nested objects) and the schema fully describes its inputs. However, being a mutation tool with no annotations and no return-value description, it could state what response success produces. The description is minimally adequate but leaves behavioral expectations unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (name, space_id) are already documented. The description adds no additional parameter meaning beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Create a new folder in a space'), identifying exactly what the tool does. However, it does not distinguish it from siblings like create_list or create_task, though the resource 'folder' is distinct enough among siblings that confusion is unlikely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as create_folderless_list, create_list, or create_space. No context is given about prerequisites like being inside an existing space, or when a folder is the appropriate container for content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only repeats the tool's core purpose and gives zero insight into side effects (e.g., whether notify_all triggers notifications, whether check_required_custom_fields validation occurs, whether creating a task with parent creates a subtask by default, or how links_to behaves). For a mutation tool with no annotation coverage, this is severely under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence, no waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
High-complexity mutation tool (19 params, no annotations, no output schema) with only 8 words of description. Schema handles parameter definitions, but the description fails to convey return behavior, side effects, or how creation relates to sibling tools like update_task or duplicate_task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 74%, meaning most parameters carry their own meaning in the schema (e.g., priority has explicit 1-4 mapping, time_estimate in ms, parent as subtask creator). The description adds nothing beyond the schema, but since coverage is above 80%... actually it's 74%, just under the 80% threshold. The description contributes zero parameter semantics, landing at the baseline-3 for a mostly-covered schema. Some parameters like notify_all, start_date, and due_date_time have no schema description either, and the tool description doesn't help fill those gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new task in a list' clearly states the verb (create) and resource (a task in a list). It distinguishes from siblings like create_list, create_folder, and create_goal, though it doesn't explicitly differentiate from update_task or the many other create_* siblings. It lacks detail about the scope/context beyond 'in a list', which is slightly vague but adequate given the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as duplicate_task, move_task_to_list, or add_task_dependency. No prerequisites are mentioned (e.g., needing list_id already obtained via get_lists), and no exclusions or when-not-to-use guidance is provided. For a creation tool with 19 parameters, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the action—'Delete a key result from a goal'—without revealing whether deletion is permanent, whether it cascades to related checklists/items, whether it requires specific permissions or ownership, or whether it's reversible. For a destructive mutation tool with zero annotation coverage, the description provides minimal warning that this is an irreversible action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. It states the action clearly and compactly. This is genuinely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete operation with no annotations and no output schema, the description is thin. It doesn't disclose effects, precondition requirements, or confirm behavior. A mutation tool at this complexity could reasonably note that deletion is permanent or reference related cascading behavior. The single-sentence description is adequate for a read-only tool but insufficient for a destructive one.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—the single parameter key_result_id is documented as 'The key result ID' in the schema. The description adds no additional parameter guidance (e.g., where to obtain the ID, format expectations). Baseline 3 is appropriate since the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a key result from a goal' has a clear verb (Delete) and resource (key result), with scope indicating it's removed from a goal. It's a single verb+resource statement that's legitimate but doesn't go beyond the obvious—the name and title already communicate exactly this. It doesn't distinguish itself from siblings like delete_goal or update_key_result, though the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as update_key_result (to modify rather than delete) or delete_goal (to remove the parent goal entirely). There's no mention of prerequisites, consequences of deletion, or whether deletion is permanent or recoverable. A single sentence offers no context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention pagination behavior, whether results are limited, auth requirements, or any side effects. The 18-parameter surface with no behavioral notes leaves the agent guessing about response shape, default ordering, or filtering semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no waste. It front-loads the core purpose immediately. However, it could have added more value in the same footprint, but as written it is appropriately tersely structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 18 parameters, 0 annotations, no output schema, and 6% schema coverage, the description is inadequate. For such a complex tool with rich filtering, the agent needs guidance on the filter semantics, param combinations, pagination, and what the returned shape looks like. None of this is provided, making the tool hard to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 6%, with 18 parameters mostly undocumented (page, tags, reverse, order_by, statuses, subtasks, assignees, etc.). The description adds essentially nothing about parameter meaning beyond 'advanced filters'. Although the parameter names hint at semantics (due_date_gt, date_created_lt, etc.), the description provides no compensation for the low coverage. This is a significant gap for a high-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get tasks across a workspace with advanced filters' clearly states the verb (get) and resource (tasks across a workspace) plus indicates filtering capability. It distinguishes somewhat from siblings like get_tasks and get_view_tasks by noting 'across a workspace' and 'advanced filters', though it doesn't explicitly differentiate from get_tasks which likely overlaps in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this vs get_tasks, get_view_tasks, or other task-listing tools. There are no exclusions, prerequisites, or alternative recommendations. The 'advanced filters' phrase implies it is richer than alternatives, but this is not made explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description doesn't mention whether this is a read-only operation, what the response format looks like, whether pagination is available, or any rate limits or authorization requirements. The start and start_id parameters hint at pagination but the description doesn't explain this behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short — one sentence, no filler. It's front-loaded with the core purpose. However, the minimalism borders on under-specification rather than genuine conciseness, which keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and only 33% schema description coverage, the description needs to compensate significantly. The two undocumented pagination parameters (start, start_id) suggest pagination behavior that the description completely fails to explain. Given the complexity of a comments endpoint with pagination, this is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% — of the 3 parameters, only list_id has a schema description, and that's just 'The list ID'. The start and start_id parameters have no description, and the tool description doesn't explain what they do. The description adds essentially no meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all comments on a list' clearly states the action (get) and resource (comments on a list), which is specific. It doesn't explicitly distinguish from siblings like get_task_comments or get_chat_view_comments, though the resource name is somewhat clear. The sibling create_list_comment suggests a related create operation exists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_task_comments or get_chat_view_comments. It doesn't mention pagination, ordering, or any filtering capabilities, nor does it clarify how start and start_id parameters might relate to pagination behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't describe the return shape, whether fields include metadata like type/options, sort order, or pagination behavior. For a read tool with zero annotation coverage, minimal behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that states exactly what the tool does. No filler or redundant content. Appropriately sized for a simple read operation with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one param and full schema coverage, this is marginally adequate. However, given no output schema and no annotations, the description could have added value by describing what fields return (names, types, options) or noting whether this is needed before setting custom field values. It's minimal but sufficient for a simple, self-explanatory GET operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single list_id parameter that has a clear description ('The list ID'). With full schema coverage and one simple parameter, the baseline 3 applies; the description adds nothing beyond schema but doesn't need to for a single obvious parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all custom fields available for a list' clearly states the verb (Get) and resource (custom fields scoped to a list). It's a clear statement of purpose but doesn't distinguish it from siblings like get_custom_task_types or set_custom_field_value, though those are distinct enough operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It doesn't clarify when this should be used before set_custom_field_value, or mention any prerequisites (e.g., whether the list needs to exist or whether custom fields need to be configured first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Update' implies mutation, but the description doesn't state how updates behave - e.g., whether unspecified fields are preserved or reset, whether events replaces the full subscription list or appends to it, or whether endpoint updates propagate immediately. For a mutation tool, this is a significant gap in behavioral clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. It names two key fields and the action. However, it's slightly under-specified given the complexity of the tool (3 updateable fields, one being an event array). Concise but could add a sentence about 'status' without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no output schema, and only 25% parameter documentation combined. Given this context, the description should compensate substantially. It names endpoint and events but misses status, provides no guidance on update semantics, no prerequisites, and no behavioral expectations for a mutation operation. A moderate-complexity mutation tool deserves more than this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only webhook_id has a description in the schema). The description mentions endpoint and event subscriptions, providing some meaning for those parameters, but it omits the 'status' field entirely and doesn't explain the semantics of the events array (full replacement vs append). With low schema coverage (under 50%), the description should compensate but only partially does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what it does: 'Update a webhook's endpoint or event subscriptions' with a specific verb (Update) and resource (webhook). It mentions two of the three updateable fields. However, it doesn't mention updating 'status' (active/inactive), which is a third field the schema exposes. Still, the core purpose is clear and distinguishable from siblings like create_webhook and delete_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites (e.g., that the webhook must exist, or that webhook_id is required). No indication of which fields are mutually exclusive or combinable, or whether partial updates are supported. The description gives no usage context whatsoever.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. 'Delete' implies destructive mutation, but the description doesn't state that deletion is irreversible, whether associated data is affected, whether permissions are required, or what the response looks like. For a destructive mutation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste, which is good. However, it's at the border of under-specification rather than genuine conciseness — a destructive operation with considerable behavioral implications gets only one terse sentence. Brevity alone doesn't earn a high score when substance is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation with no annotations, no output schema, and only one parameter. For a delete operation, the description should at minimum note irreversibility, any cascading effects, or permission requirements. The one-parameter tool has minimal complexity, which raises the baseline slightly, but the destruction semantics warrant more disclosure than provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (view_id documented), so baseline is 3. The description adds no information beyond the schema — the view_id parameter is self-explanatory. The description doesn't add format, scope, or constraint details, but the schema alone adequately documents the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a view' has a clear verb (delete) and resource (view), establishing the core purpose. It doesn't explicitly distinguish from siblings, but 'delete_view' is unique among siblings (there's no competing delete of views), so the purpose is clear though minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are sibling tools like get_view, get_list_views, get_workspace_views etc., but no context clarifies that deletion should only occur after confirming the view exists, or that this is irreversible. No exclusions or alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds no behavioral context: no mention of pagination behavior, ordering, rate limits, or whether this returns only top-level comments vs nested replies. For a read tool with zero annotation coverage, this is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. However, it is under-specified for the tool's capability — 'all comments' plus pagination parameters (start, start_id) implies more complexity than the short description addresses. It's concise but borderline terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description must carry more weight. It fails to mention the return format, ordering guarantees, whether threaded replies are included, or how pagination works with the start/start_id cursor parameters. For a tool with 5 parameters and related sibling comment tools, this is notably incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60% with 5 parameters. The description contributes nothing about parameters beyond the schema. team_id and custom_task_ids have no schema descriptions, and the description does not compensate for these gaps. However, it does not actively mislead either. Baseline 3 is appropriate given partial coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all comments on a task' clearly states a specific verb (Get) and resource (comments on a task). It clearly distinguishes from siblings like get_list_comments, get_chat_view_comments, and get_threaded_comments, which operate on different comment scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs get_threaded_comments or get_list_comments. The description doesn't clarify relationships between task comments and threaded comments, nor does it note any pagination caveats despite having start and start_id parameters. Sibling tools operating on comments exist, but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. 'Edit' implies mutation but doesn't disclose permissions needed, whether partial updates are supported, or what happens to unmentioned fields. No mention of thread behavior or comment-type restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single short sentence is efficient, but it's under-specified rather than genuinely concise. With 4 parameters, no additional structure or param clarification is provided, so brevity comes at the cost of usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A mutation tool with no annotations, no output schema, and 50% param coverage is under-specified. Does not clarify which comment types this applies to (task vs list vs threaded), whether it updates the comment text only or also status fields, or what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (comment_id and comment_text documented). The description adds minimal value beyond the schema. The 'assignee' and 'resolved' parameters are undocumented, and the description does nothing to clarify their meaning or relationship to editing a comment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource ('Edit an existing comment'). Distinguishes from create_task_comment/create_list_comment (creation) and delete_comment (deletion), though it doesn't explicitly name them. A bit generic but unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives like create_task_comment or create_list_comment. Does not specify which comment types it edits (task, list, chat view). No context on prerequisites or when editing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. As a creation tool, it implies a mutation (creating a space tag), but it doesn't disclose whether the tag is immediately available for tasks, whether duplicate names are rejected, whether there are limits on tag counts, or what happens on duplicate creation. For a mutation tool with zero annotation coverage, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately terse for a simple creation tool, though it could add a touch more value. It's not padded or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and 4 parameters, the description is minimal. It doesn't explain tag semantics (how tags relate to tasks), uniqueness constraints, color format expectations, or error behavior. Since get_space_tags and add_tag_to_task are sibling tools, context about tag lifecycle would help the agent understand the tool's role. The description does the bare minimum.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (space_id, name, tag_bg, tag_fg) are documented in the schema itself. The description adds no additional parameter meaning—it doesn't clarify that tag_bg and tag_fg are optional display properties, that name should be unique within the space, or that space_id must reference an existing space. Baseline 3 is appropriate when the schema carries the informational load, but the description contributes nothing beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new tag in a space' has a specific verb (Create) + resource (tag) + scope (in a space), clearly distinguishing it from siblings like get_space_tags, update_space_tag, and delete_space_tag. It could mention what a tag is used for, but the core purpose is clear and distinct from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There's no mention that this is a prerequisite before assigning tags to tasks (add_tag_to_task), or that you should check existing tags with get_space_tags first to avoid duplicates. The description gives no usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Permanently' hints at irreversibility, which is useful, but the description doesn't disclose cascading deletions (what happens to contained lists, tasks, folders), permission requirements, or error conditions. For a destructive tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence, 'Delete a folder permanently'—no wasted words or redundant content. It's appropriately brief for a simple destructive operation. It doesn't restate parameter names or duplicate schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a destructive mutation with no annotations and no output schema, so the description must compensate. It fails to disclose what happens to nested resources (child folders, lists, tasks) when a folder is deleted, whether there are confirmation/soft-delete safeguards, or permission requirements. For a destructive operation, this is incomplete and leaves an agent guessing about cascading effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a single documented parameter (folder_id: 'The folder ID'), so the baseline of 3 applies per the rubric. The description adds no additional meaning beyond what the schema provides—it doesn't clarify the ID format, how to obtain it, or any constraints. With only one well-documented parameter, the schema does the heavy lifting adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a folder permanently' clearly states the verb (delete) and resource (folder), and communicates the action is permanent. The sibling tools include get_folder, create_folder, update_folder, delete_list, and delete_space, but the folder-specific scope is clear enough to distinguish it from delete_space and delete_list. However, it doesn't differentiate itself from potential alternatives or clarify whether it only deletes empty folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives or prerequisites. It doesn't address whether the folder must be empty, whether its lists/tasks are also deleted, or any cascading behavior. There's no mention of when-not-to-use or alternative deletion methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden of behavioral disclosure. It fails to state that this is a destructive/irreversible operation, whether permissions are required, whether cascading deletion of key results occurs, or what the response looks like. For a mutation tool with zero annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with zero waste. While minimal, it is appropriately sized for the trivial one-parameter scope of the tool. However, the brevity comes at the cost of behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations and no output schema, the description is insufficiently complete. It doesn't address cascade behavior, irreversibility, or idempotency. Given sibling delete tools exist (delete_key_result, delete_space_tag), more context on distinctions would help the agent choose correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (goal_id described as 'The goal ID'). The description adds no additional meaning beyond the schema, which is the baseline 3. No compensation provided for any nuances about the format or source of the goal_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a goal' with a specific verb and resource. While clear, it doesn't distinguish from delete_key_result or other delete tools, and there's no elaboration on scope (e.g., whether it cascades). It's unambiguous for the core purpose but lacks differentiation from sibling delete operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites (e.g., whether goal must exist), and no exclusions or conditions. The agent gets no context about scenarios where deletion might fail or be inappropriate, such as goals with active key results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not disclose whether deleting a tag also removes it from all tasks that use it, whether the operation is reversible, permission requirements, or the effect on existing task-tag associations. For a destructive mutation with no annotations, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero filler words. It's appropriately sized for a straightforward delete operation. Nothing extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, no output schema, and a scope limited to two simple params, the description should disclose behavioral risks (tag removal cascade effects on tasks, irreversibility). The current description is complete only in that the purpose and params are clear, but fails to communicate the mutation's side effects, which is a real gap for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (space_id, tag_name) are already documented with basic descriptions. The description adds nothing beyond the schema for either parameter. Baseline 3 is appropriate when schema fully documents parameters, though it doesn't hint at additional context like tag_name being case-sensitive or exact-match.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a tag from a space' uses a specific verb (delete) and clearly names the resource (tag) and its container (space). It distinguishes itself from siblings like create_space_tag/update_space_tag and remove_tag_from_task (which removes tags from tasks rather than deleting them from spaces).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the name makes the purpose clear relative to add/update tag tools, there is no explicit context about when to delete a space tag versus remove_tag_from_task, or any constraints (e.g., what happens to tags already assigned to tasks). No when-not or alternative guidance given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It fails to disclose that deletion is typically irreversible/destructive, requires appropriate permissions, what happens to associated tags or data, or whether batch deletion is atomic. 'Delete' implies mutation but gives no warning about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero wasted words. It conveys the action, the resource, and the batch aspect compactly. While minimal, it is appropriately terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description should provide more context. It doesn't address irreversibility, permission requirements, edge cases (deleting running timers), or behavior on non-existent IDs. As a batch delete operation, this warrants additional explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (team_id and timer_ids) fully. The description adds no semantic value beyond the schema, making baseline 3 appropriate. The schema's field descriptions are adequate on their own.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete one or more time entries' clearly states the verb (delete) and resource (time entries), including the fact that it supports batch deletion. It distinguishes well from siblings like create_time_entry and update_time_entry, though it doesn't explicitly differentiate from the similar update_time_entry or note scope limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives. It doesn't mention that deletion is permanent/irreversible, whether running timers can be deleted, or contrast with siblings like stop_timer or update_time_entry. The description provides no usage context beyond the basic action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete' implies a destructive, irreversible operation, but the description doesn't disclose whether deletion is permanent, whether it cascades to related resources, whether authentication/special permissions are required, or what happens to in-flight webhook deliveries. For a destructive operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. While it could say more about behavioral aspects, it doesn't pad with unnecessary content. However, this borders on under-specification rather than intentional conciseness, holding it back from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a destructive mutation tool with no annotations and no output schema. The one-parameter simplicity helps, but for an irreversible delete operation, the absence of any disclosure about side effects, reversibility, or confirmation behavior leaves the agent with an incomplete picture. Sibling tools like delete_space or delete_goal likely have similar profiles, but this tool alone provides insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter 'webhook_id' whose description is 'The webhook ID'. The description adds nothing about the parameter beyond the schema. The entire tool is simple enough that the schema adequately documents the parameter, but the description provides zero additional semantic value. Baseline 3 is appropriate since schema does the heavy lifting for the one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Delete a webhook" clearly states the verb (delete) and resource (webhook), which is immediately clear for a simple operation. It distinguishes adequately from siblings like get_webhooks, create_webhook, and update_webhook since the action verb differs, though it doesn't add any behavioral nuance beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing to delete a webhook before deleting associated resources), no exclusion criteria, and no mention of cases where deletion might fail or be inappropriate. The description gives no context for selectability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure burden. The description is a terse one-liner that doesn't disclose whether this requires specific permissions, whether pagination applies, what information each view includes, or what the return structure looks like. For a retrieval tool with zero annotation coverage, more behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero waste. It's front-loaded with the verb and resource. While minimal, there's nothing extraneous to remove.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple 1-parameter retrieval tool with no output schema and no annotations. It's a list-fetching operation whose return shape (view objects, fields, pagination) is entirely unspecified. While simple, the total absence of behavioral or return information leaves the agent guessing about the response format. More context on the return structure or view definition would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single parameter (folder_id) described as 'The folder ID'. The description adds minimal value beyond this, just implying folder scope. Baseline 3 is appropriate since the schema fully documents the only parameter and the description's contribution is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all views for a folder' uses a specific verb (Get) plus resource (views) and scope (folder), clearly distinguishing from siblings like get_space_views, get_workspace_views, get_list_views, and get_view. It's clear what the tool does, though it doesn't elaborate on details beyond the folder requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like get_view, get_space_views, get_workspace_views, or get_view_tasks. The tool is for a folder-scoped view listing, but there's no explicit when/when-not guidance or mention of related alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, which is a reasonable inference, but the description doesn't disclose anything about pagination, whether all members are returned in any special order, or whether this returns member details or just IDs. For a read tool with no annotations, this is minimally acceptable but lacks behavioral depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It efficiently states the core function. It's appropriately sized for a simple tool with one parameter, though it could arguably include a bit more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read operation with fully documented schema, the description is reasonably complete. However, without annotations and without an output schema, there's no disclosure about what the returned member data looks like (IDs only vs. full member objects), which could affect how an agent uses the results. Given the tool's simplicity, this is acceptable but not excellent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with 'list_id: The list ID', which fully documents the single required parameter. The description doesn't add any additional parameter semantics beyond what the schema already provides. With high schema coverage, the baseline of 3 is appropriate since the schema correctly handles the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all members of a list' has a specific verb (get) and resource (list members), clearly indicating it retrieves members for a given list. However, it doesn't distinguish itself from the many similar 'get_*' sibling tools like get_task_members, get_space_members, or get_workspace_members, which all follow the same pattern but operate on different resources. The purpose is clear but not differentiated from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are several member-related tools in the siblings (get_task_members, get_space_members, get_workspace_members, get_guest) that an agent could confuse this with. No context is given about prerequisites, list types, or scenarios where this is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't mention whether this is a read-only operation, whether pagination applies, what happens with the archived parameter default, or any rate-limit or auth considerations. A read tool with this many siblings should clarify its read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with no wasted words. Efficient, though could not be considered overly terse since it accomplishes the basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with 100% schema coverage and no output schema, the one-line description is mostly adequate. However, given the presence of get_folderless_lists and get_list as siblings, some clarification on list scoping (folder-specific vs folderless) would improve completeness. The archived parameter behavior could also be clearer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are documented in the schema. The description adds no param detail beyond what the schema already provides, so baseline 3 is appropriate. The archived parameter's default behavior is not clarified anywhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Describes 'Get all lists in a folder' with a specific verb+resource+scope. Clear distinction from siblings like get_list (single), get_folderless_lists, and create_list. Slightly underspecified on return behavior but the core purpose is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when/when-not guidance provided. The description doesn't explain when to use this versus get_folderless_lists, get_list, or get_tasks. An agent must infer context from the sibling names without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description is a terse restatement of what the tool does with no mention of return format, error cases (e.g., invalid space_id, non-existent space), auth requirements, or any side effects (though for a GET this is minor). It doesn't disclose what 'details' actually includes or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It's optimally front-loaded and easy to parse. However, it's somewhat under-specified even while being concise — conciseness at the cost of useful content grades slightly below a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with no annotations, no output schema, and only a one-line description, the description is quite sparse. While it's a simple tool, 'Get details of a specific space' leaves the agent without clarity on what fields will be returned, how it differs from get_spaces, or what 'details' means in this API's context. A slightly more descriptive sentence would create a more complete picture for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the schema already documents the single space_id parameter. The description doesn't add meaning beyond what the schema provides — it says nothing about the format of space_id, where to obtain one, or any constraints. As the baseline for high coverage is 3 and the description adds no additional parameter nuance, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific space' clearly states a specific verb (get) + resource (space), indicating it retrieves details for one space by ID. While it doesn't explicitly distinguish from siblings like get_spaces (plural) or get_workspace, the singular 'specific space' plus the required space_id parameter implies the distinction from listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. The sibling set includes get_spaces, get_workspace, and other get_X tools, but the description doesn't clarify when to reach for this specific one (e.g., 'use get_space when you have a known space_id, use get_spaces to list all'). Usage must be inferred entirely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It's a read-type operation but the description doesn't state what happens for invalid space_ids, whether pagination applies (important since it returns 'all' members which could be large), or what the return format looks like. For a retrieval tool with no annotation coverage, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words. It states exactly what the tool does. Nothing to trim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter retrieval tool with no annotations and no output schema, the description is minimal but arguably sufficient. However, it doesn't clarify whether 'all' means paginated results, whether members include guests, or how the response is structured. Given the many member-related sibling tools, more context distinguishing space-level membership would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—the single parameter space_id is described as 'The space ID' in the schema. The description adds no additional meaning beyond what the schema already documents. Baseline 3 is appropriate since the schema already handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Get all members of a space" uses a specific verb (get) and resource (members of a space). It clearly indicates the return is a collection of all members. It doesn't explicitly distinguish from sibling tools like get_workspace_members, get_list_members, or get_task_members, but the resource scoping (space) is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like get_workspace_members, get_list_members, or get_task_members. Given many member-related sibling tools exist, this is a notable gap—an agent could confuse which level (space vs workspace vs list vs task) applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not specify whether this is a read-only operation, whether it returns an array or a paginated list, what happens if the space doesn't exist or has no tags, or whether authentication/space membership is required. For a tool with zero annotation coverage, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. It's appropriately minimal for a simple getter tool. While it could front-load more detail, the brevity is acceptable given the low tool complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple signature (1 param) but also has no output schema and no annotations. The description doesn't mention return format, pagination behavior, error handling for invalid space_id, or the relationship between tags and tasks. Given that it's a read operation in a larger API surface, more context about the return shape would be valuable. The description is adequate for locating the tool but leaves behavioral details to be discovered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with the single parameter space_id documented as 'The space ID'. The description adds no additional meaning beyond what the schema provides. With full schema coverage, the baseline of 3 is appropriate since the schema handles the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all tags defined in a space' clearly states a specific verb (get) and resource (all tags in a space). It accurately reflects the function and distinguishes from siblings like create_space_tag, update_space_tag, and delete_space_tag, which are mutation operations. It's clear but doesn't elaborate on the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives such as get_time_entry_tags, add_tag_to_task, or create_space_tag. There is no context about typical usage scenarios, prerequisites (e.g., needing space access), or whether alternatives would be more appropriate for tag-related queries. Only the name implies the scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. The description gives none — it doesn't mention pagination behavior, whether archived/closed tasks are included by default, rate limits, ordering defaults, or whether subtasks are excluded by default. Given the wide array of filter and boolean parameters, the description omits critical default-behavior information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words ('Get tasks from a list with optional filters'). It's appropriately brief for a tool whose schema carries most of the parameter documentation. It's not verbose, though it could arguably front-load slightly more semantic useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex tool with 17 parameters and no output schema and no annotations. The one-sentence description is insufficient for such complexity. It doesn't explain default behaviors (are closed/archived tasks excluded by default? is pagination standard?), what ordering defaults apply, or how filters combine. With no output schema and no annotations, the description should compensate but doesn't.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 94%, so the input schema documents nearly all parameters well. The description adds little beyond 'optional filters' as a general concept. Per the rubric, high schema coverage sets the baseline at 3, and the description doesn't add meaningful parameter insight beyond the schema. The 6% uncovered portion is negligible.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Get tasks from a list with optional filters'). It clearly distinguishes from siblings like get_task (singular) and get_filtered_team_tasks by specifying it operates on a list scope. However, it doesn't explicitly state what distinguishes it from get_list or get_view_tasks, which also retrieve tasks for a list/scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description mentions 'optional filters' but doesn't state what the default behavior is (e.g., are closed tasks excluded by default?), nor when one would prefer get_filtered_team_tasks or get_view_tasks. There are no when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read operation, but the description doesn't clarify whether the watcher list includes current user, whether it requires any special permissions, what the return format is, or pagination behavior for large watcher sets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, efficiently conveying the purpose with zero wasted words. It's appropriately short for a tool with one simple parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward read tool with one parameter, the description is somewhat minimal. No output schema exists, so the return format (what a watcher object looks like) is undocumented. The description doesn't address whether the task must exist, error cases, or whether watchers differ from members. It's adequate for simple resolution but lacks depth for an agent needing robust guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there's only one parameter (task_id) described as 'The task ID'. The description's word 'of a task' reinforces that task_id refers to the specific task whose watchers are returned, providing marginal added context. With a single param at full schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all watchers of a task' uses a clear verb+resource structure ('Get...watchers of a task'), which clearly states what the tool returns. It distinguishes from siblings like add_task_watcher/remove_task_watcher by focusing on retrieval, though it could be stronger by clarifying it's read-only versus get_task_members which also retrieves task-related members.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. Nearby siblings get_task_members, get_task, get_tasks exist, but there's no note clarifying watchers vs assignees vs members. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It confirms this is a read operation but doesn't describe whether pagination is supported via start/start_id, what the response shape looks like, or any performance/rate-limit implications. For a read tool with zero annotation coverage, more behavioral detail would be expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. It's front-loaded and concise, though it's arguably too terse given the pagination parameters that need explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and only 33% schema coverage, the description is under-equipped. It doesn't explain the pagination model (start vs start_id), how threading works, or what distinguishes threaded replies from regular comments. For a read tool with additional parameters, this leaves notable gaps in agent comprehension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the description should compensate for the undocumented 'start' and 'start_id' parameters. The description adds no meaning for these parameters, leaving the agent to guess how pagination works. The comment_id parameter is described in the schema ('The parent comment ID'), which helps, but the two pagination params are entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get threaded replies on a comment' clearly states the verb (get), resource (threaded replies), and target (a comment). It distinguishes itself from siblings like create_threaded_comment, get_task_comments, and get_list_comments, though it could be more specific about the scope (does it return a single thread or all threads under the parent?).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_task_comments or get_list_comments. There's no mention of the relationship to create_threaded_comment, nor when one would fetch threaded replies vs flat comments. The description gives no context about pagination, which is relevant given the 'start' and 'start_id' parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, the description provides no behavioral details: no pagination info, no indication of how many entries are returned, no mention of authorization/permissions needed, no sorting or limit semantics. The description adds minimal behavioral context beyond the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, zero waste. It's appropriately brief for a simple list-retrieval tool. No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderately complex tool with 11 parameters, 64% undocumented by schema, no output schema, and no annotations. The description does not clarify the relationship between filters (e.g., must start_date come with end_date? mutually exclusive filters?), whether result is paginated, or what the return structure looks like. For a tool with this many filter parameters and rich siblings, the single-line description is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low at 36%, with 5 of 11 parameters lacking descriptions (list_id, task_id, space_id, folder_id, custom_task_ids, include_task_tags, include_location_names have no description). The description says 'optional filters' which maps to the parameter set generically, but the term 'filters' does add some conceptual framing. The description doesn't compensate for the 64% gap in undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource+scope: 'Get time entries for a workspace with optional filters.' It clearly distinguishes this from siblings like get_time_entry (singular), create_time_entry, update_time_entry, and start_timer/stop_timer. While it doesn't mention the return format or that this is a list operation, the verb-resource-scope structure is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool vs alternatives. There are multiple time-related siblings (get_time_entry, get_running_timer, get_time_entry_tags), and the description doesn't explain when to prefer this over get_time_entry or distinguish between them. Usage context is entirely implied by the name and 'workspace' scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It states a read operation ('get all webhooks'), implying non-destructive behavior, but doesn't mention whether webhooks are ordered, paginated, or what fields they return. The description offers minimal behavioral context beyond a read hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words. It is appropriately sized for a simple list operation. Could arguably be more descriptive, but for a single-parameter read tool, the conciseness is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with no output schema and no annotations, the description does reasonable but minimal work. It doesn't describe potential edge cases like empty results, pagination behavior, or error conditions. Given the low complexity, this is adequate but leaves room for more completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and there is only one parameter (team_id) which is clearly described as 'The workspace/team ID'. The description adds 'for a workspace' which aligns with the parameter meaning, but adds no additional semantic detail beyond the schema. Baseline 3 is appropriate for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all webhooks for a workspace' states a clear verb ('get') and resource ('webhooks') scoped to a workspace. However, it doesn't distinguish from siblings like create_webhook, update_webhook, and delete_webhook, though the verb 'get' and plurality 'all webhooks' offer some differentiation from mutations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of pagination, result limits, or mention that this is a read operation listing all webhooks. No exclusions or alternatives are named, such as distinguishing from get_workspaces or other list-type tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It doesn't reveal whether this returns paginated results, the return format, behavior with invalid team_id, authentication requirements, or whether guests/inactive members are included. For a read tool with zero annotation coverage, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence with zero waste. It front-loads the verb and resource clearly. Could arguably be judged under-specified rather than concise, but the text it does contain is well-formed and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-listing tool with one parameter and no output schema. The description names the purpose and parameter is covered by schema. However, with no annotations and no behavioral context (pagination, return shape, filtering), it falls short of complete for a list-type tool. Baseline information is present but nothing more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter (team_id, 'The workspace/team ID'). The description doesn't add semantics about what the ID format is or where to obtain it, but the schema adequately documents the only parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all members of a workspace' uses a specific verb (get) and resource (workspace members), clearly stating the scope ('all'). It distinguishes from siblings like get_task_members, get_list_members, and get_space_members, which target different resource types, though it doesn't explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this vs related tools like get_space_members, get_task_members, or get_list_members. The distinction between workspace, space, list, and task membership is implied but never stated. No exclusions, prerequisites, or context about when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states 'Get the current plan' with no mention of what the return value looks like, whether this requires admin/owner privileges, or whether it reflects a free/trial/paid tier. For a read-only retrieval with zero annotation coverage, more context 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded but is underspecified — it's a complete sentence with no waste, yet it doesn't convey enough context given the minimal annotation coverage. It's appropriate for length but leaves gaps in information density.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one simple parameter, 100% schema coverage, and a read-only operation, the description is mostly adequate. However, no output schema and no annotations mean the description should clarify what 'plan' entails (e.g., tier, limits, billing) to help the agent know if the return matches the user's intent. Minimum viable, with clear room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning team_id is already documented as 'The workspace/team ID' in the schema. The description adds no additional parameter meaning beyond the schema, so baseline 3 is appropriate given the schema handles the parameter documentation fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Get the current plan for a workspace' — a specific verb+resource combination that clearly identifies the retrieval of a workspace's subscription/plan. It is distinguishable from siblings like get_workspace (general workspace info) and get_workspaces (list). Clear enough though it doesn't explicitly note scope limitations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus get_workspace or get_workspace, no mention of required access levels or contexts where plan info would be relevant. The agent must infer usage from the name and sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Remove' implies a destructive/mutating operation, but the description doesn't disclose what happens to the guest's associated data (tasks, comments, assignments), whether the operation is reversible, or whether special permissions are needed. For a destructive operation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence, highly efficient with no filler. Slightly under-specified but the conciseness itself is not the issue, hence a 4 rather than 5 since it could afford a bit more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is minimal. It doesn't explain return values, error conditions, side effects on guest-linked data, or permission requirements. The 2-parameter schema is simple, but the operational semantics of removing a guest from a workspace deserve more coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (team_id and guest_id) are already documented in the schema. The description adds no parameter-specific detail beyond the schema. Baseline 3 is appropriate when the schema covers everything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (remove), the resource (guest user), and the scope (from a workspace). It distinguishes from siblings like invite_guest_to_workspace and get_guest, though it doesn't explicitly contrast itself. Clear verb+resource+location relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no caveats about prerequisites (must the guest exist? must they be in the workspace first?), and no exclusion criteria. The sibling get_workspace_members and invite_guest_to_workspace suggest related workflows but no guidance is provided connecting them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It doesn't disclose whether removing a tag affects the tag itself (deleting it) or just the association, whether it requires permissions, what happens if the tag doesn't exist, or error/edge-case behavior. This is a mutation operation with zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single short sentence with zero wasted words. Efficient and to the point, though it's arguably under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no output schema, and a fairly terse description covering only 2 parameters. It doesn't explain the relationship between tag removal and the tag system (space tags, task tags), what constitutes a tag_name value, or any side effects. For a write operation, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both task_id and tag_name documented. The description adds no additional parameter meaning beyond the schema, but given full schema coverage, the baseline of 3 is appropriate. It doesn't clarify the format constraints on tag_name (e.g., case sensitivity).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a tag from a task' clearly states the verb (remove) and resources (tag, task). It's distinct from the sibling add_tag_to_task which does the inverse operation. However, it doesn't specify particular edge cases or scope beyond the basic operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. With siblings like add_tag_to_task and the various tag-management tools (create_space_tag, update_space_tag, delete_space_tag), there's ambiguity about whether this removes a task-tag association or affects the tag itself. No conditions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether this mutates data, whether the field must exist beforehand, what happens if the field is read-only, or what the response contains. For a setter/mutation tool with zero annotation coverage, more behavioral detail 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It conveys the core operation compactly. It's appropriately short for a simple setter tool, though it could have added one clause about field-ID provenance without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool (setter) with no annotations, no output schema, and no usage guidance. The description doesn't explain how to obtain field_id (e.g., via get_list_custom_fields), whether values are validated, or what errors might occur for wrong field types. For a 3-parameter mutation tool, this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema documents task_id, field_id, and value. The description itself adds no parameter-level information beyond the schema. The value parameter has a generic description ('type depends on the field type') which is somewhat weak but the schema does cover it. Baseline 3 is appropriate since the schema carries the load here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource combination: 'Set the value of a custom field on a task'. It identifies what is being modified (custom field value) and on what entity (task). It doesn't explicitly distinguish from the sibling tool 'remove_custom_field_value', but the contrast is reasonably obvious given the verb difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like remove_custom_field_value, or how it relates to update_task. No prerequisites are mentioned, such as needing the field to already be defined on the task or the task type. The description provides no usage context at all beyond the basic operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the action (stop timer) but doesn't reveal the return value, whether it errors if no timer is running, whether it's idempotent, or what state changes occur beyond stopping. For a state-mutating action with zero annotation coverage, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single clear sentence with zero wasted words. It's appropriately concise and front-loaded with the verb and action. Not padded with unnecessary qualifiers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There's no output schema, no annotations, and only one parameter documented by schema. For a mutating action on a timer, the description doesn't explain tie-break behavior if multiple timers exist, error handling when no timer is running, or what the response indicates. It's functional but leaves meaningful edge cases unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter 'team_id' documented as 'The workspace/team ID'. The description mentions 'authenticated user' but doesn't explain why team_id is required or how it relates to the timer lookup. The description adds minimal value beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description "Stop the currently running timer for the authenticated user" has a specific verb (Stop) and resource (the currently running timer), and clarifies the scope (authenticated user, single currently-running timer). It distinguishes from siblings like start_timer and get_running_timer. However, it doesn't explicitly state what happens if no timer is running, which would be slightly more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives. Context implies you'd use this after checking get_running_timer, but the description doesn't mention this relationship or any prerequisite (e.g., verifying a timer exists first). No explicit when-not or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. 'Update' implies mutation, but the description doesn't disclose what happens on partial updates (e.g., whether unspecified fields are preserved), whether changes propagate to linked tasks, or any permission/authorization requirements. It also doesn't warn about effects on nested items or order when reordering. For a mutation tool with zero annotation coverage, this is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with a parenthetical enumerating the update capabilities. It wastes no words and gets to the point quickly. The parenthetical is efficient at conveying scope. However, it's slightly too terse given the lack of annotations—it could afford one more sentence for behavioral context while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and 6 parameters (of which several are optional fields with semantic nuance), the description is thin. It doesn't explain return behavior, validation rules, prerequisite checks, or interaction between parameters (e.g., whether parent and resolved can be set together). A user updating a checklist item would benefit from knowing update semantics. The schema covers 83% but the description doesn't compensate for the missing behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 83%, so the schema documents most parameters well (parent, assignee, resolved, checklist_id, checklist_item_id all have descriptions). The description's parenthetical list (rename, check/uncheck, reassign, reorder) adds value by mapping to which parameters correspond to which operations, especially hinting at reorder behavior not fully explicit in the schema. However, no parameter beyond what the schema states is clarified, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb (update) and resource (checklist item) with a parenthetical enumerating the update dimensions: rename, check/uncheck, reassign, reorder. This is clear and distinguishes it from sibling tools like create_checklist_item and delete_checklist_item. It doesn't mention nesting/reordering explicitly in the description (though 'reorder' is implied), which rounds out the purpose well.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool vs alternatives. With siblings like create_checklist_item, delete_checklist_item, and update_checklist present, the agent gets no direction on when modifying an existing item via this tool is appropriate versus recreating it. No exclusions or contextual triggers are mentioned. This is a significant gap given the rich sibling landscape.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Update' implies mutation, and 'archive' suggests a state change, but the description doesn't state whether archiving is destructive, reversible, whether it cascades to child lists/tasks, or what the response looks like. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence that wastes no words. It conveys the two primary operations (rename, archive) without redundancy. Could arguably mention more, but at this length it's appropriately brief for what it does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and only 33% parameter coverage, the description is under-specified. It doesn't explain the archived flag semantics, whether rename conflicts are possible, permissions required, or the effect of archiving on child resources. Given the complexity of folder operations, more context is warranted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only folder_id has an in-schema description). The description adds the semantic meaning of the two remaining params — name means rename target, archived means archive state — which partially compensates. However, it doesn't clarify whether archived=true archives and archived=false un-archives (or is a no-op), which is a meaningful semantic ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb+resource ('Rename or archive a folder'), which clearly maps to the tool. However, it doesn't explicitly distinguish from siblings like create_folder, delete_folder, update_space, or update_list, though the verb+resource clarity is sufficient to infer the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Given the many folder/space/list update tools, it doesn't clarify when renaming or archiving a folder is appropriate, whether archiving is reversible, or what happens to contained lists/tasks when archived. There are no exclusions or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. As a mutation tool, it should mention whether creation requires specific permissions, whether features like multiple_assignees or the features object have defaults when omitted, and what the success response looks like. None of this is disclosed, leaving the agent to guess about required permissions and default behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no wasted words. However, it is arguably under-specified for a tool with 4 parameters including a complex nested features object, so it's concise but lean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with zero annotations and no output schema, the description should explain default behaviors (e.g., what happens if features/multiple_assignees are omitted), permission requirements, and the shape of the created resource. None of this is provided, and the description only states the most obvious part of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 50%, meaning two parameters (name, team_id) are described in the schema but the features object and multiple_assignees lack descriptions. The description itself adds no parameter detail, but the features structure is self-documenting via its nested boolean 'enabled' fields. The baseline of 3 applies with 50% coverage; the nested feature keys are intuitive enough to not need much explanation, warranting a slight bump.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new space in a workspace' uses a specific verb (create) + resource (space) + location (workspace), which clearly states the tool's action. It distinguishes from siblings like update_space and delete_space, though it doesn't differentiate from create_folder, create_list, or other 'create' tools beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing an existing workspace), when spaces are needed vs folders/lists, or any exclusionary guidance. The context of 'space' as a container entity is implied but never explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't state that creating a webhook persists a subscription, that events will be POSTed to the endpoint, that the endpoint must be publicly accessible/HTTPS, that there are rate limits or delivery retries, or what happens on failure. The security implication of exposing an endpoint and the ongoing nature of the subscription are not disclosed. This is a meaningful gap for a creation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero wasted words. It's appropriately front-loaded with the core purpose. However, given how much behavioral and usage context is missing, additional sentences would have been warranted—brevity here borders on under-specification rather than genuine conciseness in service of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 7 parameters, no annotations, and no output schema, the description should do substantially more. The events/schema combination gives good parameter-level detail, but nothing covers setup requirements (public HTTPS server, authentication/verification of the webhook), what the response returns (webhook ID? secret?), or lifecycle management guidance. Completion isn't required—the description is inadequate for an agent to confidently set up and verify a webhook.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all 7 parameters well, including the full enum list for events. The description adds the key semantic detail that ['*'] subscribes to all events, which is valuable shorthand beyond the schema. The behavioral scope options (list_id, task_id, space_id, folder_id) are named in the schema but their mutually-exclusive or combinable nature isn't clarified, though this is minor given strong schema coverage. Baseline 3 + bonus for the wildcard note = 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a webhook to receive real-time ClickUp events' clearly states the verb (create), resource (webhook), and purpose (receive real-time events). It distinguishes from siblings like get_webhooks, update_webhook, and delete_webhook, which are clearly different operations. A 5 would require more specific scope detail (e.g., what entities can be subscribed), but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. The description doesn't explain when to choose this over alternatives, how webhooks compare to polling via get_tasks, or what the endpoint needs to be prepared to handle. No exclusions or prerequisites (like public HTTPS requirement or server setup) are mentioned. Sibling tools like get_webhooks/update_webhook imply lifecycle context but that's not conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided (no readOnlyHint, no destructiveHint), the description carries the full burden of behavioral disclosure. It does not state whether this is a safe read operation, whether authorization/workspace membership is required, whether pagination or limits apply, or what the returned shape looks like (list of tag objects with which fields).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero redundancy or waste. It is appropriately front-loaded and minimal for what it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool with full schema coverage, the description is adequate for basic invocation. However, with no annotations and no output schema, it doesn't disclose return format, pagination behavior, error conditions, or authorization needs. It's minimally viable but could more fully account for the missing annotation burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% – the single parameter team_id is documented as 'The workspace/team ID'. The description adds the scope that tags belong to a workspace, which slightly reinforces the parameter semantics, but there is no extra detail about format (numeric vs alphanumeric) or where to find the ID beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get all time entry tags for a workspace' – a clear verb (Get) + resource (time entry tags) + scope (workspace). It's a read operation distinct from tag CRUD siblings, but it doesn't clarify whether 'all' means all tags across the workspace or just tags used by time entries, nor does it differentiate from get_space_tags, which could be confused as a sibling alternative for retrieving tags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope ('for a workspace') is implied but there is no explicit when-to-use guidance or exclusion of alternatives. Given sibling tools get_space_tags and various tag CRUD tools exist, the description could clarify whether this returns tags specifically attached to time entries versus all workspace tags, and when one should prefer get_space_tags instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It confirms this is a create/mutation operation via 'Add', but doesn't disclose what happens on success (return format), ownership and validation requirements, whether 'automatic' type requires list_ids/task_ids to be set, or edge cases. For a creation tool with 6 required params, this is thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with no wasted words. It front-loads the verb and resource immediately and adds a clarifying parenthetical. Perfectly sized for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters (6 required), 100% schema coverage, and no output schema, the description is minimal but the schema does substantial lifting. However, the tool has complexity around 'automatic' type key results (which reference list_ids/task_ids), and the description doesn't explain when to use automatic vs manual tracking or how steps_start/steps_end work for boolean types. For 9 params with no output schema, some behavioral completeness is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all 9 parameters already have descriptions in the schema. The description itself adds no param information. However, the tool description contextualizes the purpose ('key result'/target to a goal) which helps understand that goal_id, name, steps_start/end relate to target tracking. Baseline 3 is appropriate since schema covers all params, though the description adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a key result (target) to a goal' uses a clear verb+resource pattern, identifying that this creates a key result attached to a goal. It distinguishes from siblings like update_key_result and delete_key_result through the 'Add' verb, though it doesn't explicitly differentiate from create_goal. The parenthetical '(target)' adds useful context that a key result is a target metric.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no when-to-use guidance, no exclusions, and doesn't mention requirements like an existing goal needing to be created first. There's no mention of prerequisites (goal must exist) or limitations. Among many sibling tools, nothing distinguishes when to use this vs alternatives beyond the 'Add' verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the action without explaining side effects, whether it notifies watchers, what happens to notification settings, or what the response looks like. Given the schema includes assignee/notify_all parameters implying notification behavior, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero wasted words. It's efficiently front-loaded and easy to scan. It's not verbose, though it's arguably under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations and no output schema. It has 4 parameters including notification-related ones whose effects are not explained. The description doesn't address notification behavior, return values, or how this differs from the many comment-related siblings. For a tool with side effects, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (task_id, assignee, notify_all, comment_text) are documented in the schema. The description adds no parameter-level detail beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting and the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a comment to a task' uses a clear verb (Add) and resource (comment to a task). It's distinguishable from siblings like create_list_comment and create_chat_view_comment which target different resources. However, it doesn't add specificity about the task context or any nuance beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use guidance or alternatives. It implies usage context (adding comments to tasks) but doesn't distinguish from comment-related siblings like create_threaded_comment or create_list_comment. The sibling set indicates when-to-use vs alternatives matters for comment tools, but the description doesn't address this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states 'Delete' implying irreversibility, but doesn't explicitly note that deletion is permanent or irreversible, doesn't mention any cascade effects on associated checklist items, and gives no success/failure behavior. For a destructive operation with zero annotation coverage, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that states the action clearly with zero wasted words. Every element earns its place and no information is redundant or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple single-parameter destructive tool with a 100%-documented schema and no output schema, the description covers the essential purpose. However, for a deletion operation, some behavioral context (irreversibility, cascading effects on checklist items) would strengthen completeness. It's adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter (checklist_id) that is clearly described as 'The checklist ID'. The description adds nothing beyond the schema, but since there's only one self-explanatory parameter fully documented in the schema, the baseline of 3 is appropriate. No additional meaning needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a checklist from a task' uses a specific verb+resource pattern, clearly stating the action (delete) and the object (checklist) plus its context (from a task). It distinguishes from siblings create_checklist/update_checklist which are obvious. It doesn't detail scope but is acceptably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives is provided. There's no mention of prerequisites (e.g., whether the task must exist, whether the checklist must belong to a specific task), no exclusions, and no note about consequences of deletion. The description gives zero context for when deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete' implies destructive mutation, but the description doesn't state whether deletion is permanent/reversible, whether it affects checklist ordering or other items, or whether the checklist must exist first. For a destructive tool with zero annotation coverage, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, complete sentence with zero waste. It's appropriately minimal for a straightforward delete operation with only two clearly-named parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of this tool (2 non-nested params, no output schema), the description covers the basic operation. However, for a destructive action with no annotations and no output schema, a bit more context about consequences (permanence, reversibility) would improve completeness. The minimal nature of the tool caps the ceiling here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (checklist_id and checklist_item_id) already have descriptions. The tool description adds no new parameter semantics beyond what the schema provides. Baseline 3 is appropriate since the schema handles documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an item from a checklist' clearly states the verb (delete) and resource (checklist item), and distinguishes it from siblings like delete_checklist (which deletes the whole checklist) and update_checklist_item. It's concise and unambiguous about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It doesn't mention that this is distinct from the broader delete_checklist operation, nor any prerequisites like needing to fetch the item ID first. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It doesn't state whether this returns paginated results, whether it's a read-only operation (obvious from 'get' but not explicitly stated), whether any plan tier restrictions apply, or what the response format looks like. For a simple get tool this is minimal but not necessarily fatal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence that states the purpose completely. Zero waste, no redundancy, appropriately front-loaded. Nothing to trim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter get tool with 100% schema coverage, the description is mostly adequate. However, with no annotations and no output schema, the tool lacks any disclosure about response shape, pagination, or plan restrictions, leaving some ambiguity for the agent in a low-context scenario.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the only parameter (team_id) is documented in the schema as 'The workspace/team ID', which is adequately self-explanatory. The description doesn't add parameter-specific detail beyond the schema, but the schema's coverage means the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all custom task types for a workspace' clearly states the verb (get), resource (custom task types), and scope (all, for a workspace). It distinguishes from siblings like get_list_custom_fields which are list-field-specific, though it doesn't explicitly differentiate between related custom-type tools since none exist among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this vs alternatives. No mention of prerequisites (e.g., workspace plan requirements), no exclusions, no mention of which workspace types support custom task types. The description gives no usage context beyond the bare purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It doesn't mention whether members differ from watchers, whether the response includes role/permission info, pagination behavior, or anything about the return structure. For a read-only retrieval tool with zero annotation coverage, this is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, zero waste. It's appropriately minimal for a simple retrieval tool. Nothing extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 param, no output schema, no nested objects), and the description adequately conveys the primary purpose. However, without annotations, it doesn't provide additional context like access control requirements or whether members differ from watchers, which given the sibling tool set would be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter task_id is fully described in the schema (100% coverage) as 'The task ID'. The description adds no further semantic meaning beyond what the schema already provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all members of a task' clearly states the verb (get) and resource (task members). It's distinguishable from siblings like get_task_watchers and get_space_members since it specifically targets task members, though it doesn't explicitly differentiate from these related member/watcher queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs. alternatives like get_task_watchers or get_list_members. The description doesn't clarify the distinction between task members and task watchers, which a user might confuse given the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'permanently' signals irreversibility, it doesn't disclose what happens to contained tasks, whether the operation requires specific permissions, or whether deletion cascades to children. For a destructive mutation with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, direct sentence with zero wasted words. The single-sentence form is appropriate for a tool with one parameter and a simple conceptual purpose. Clearly front-loaded with the action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 param, no output schema, no nested objects), so structural complexity is low. However, for a destructive operation with no annotations and no behavioral disclosure about side effects (cascading deletions, permissions), the description is incomplete for an agent that needs to understand consequences before invoking a delete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the sole parameter list_id has a description ('The list ID'). The description implicitly confirms the list param is required for the deletion target. With a single string parameter and full schema documentation, the description adds adequate meaning; there's minimal parameter semantics to explain beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('delete') and resource ('list') with 'permanently' signaling irreversibility. It distinguishes from siblings like update_list, get_list, and create_list which all operate on lists. However, it doesn't explicitly state the scope (e.g., workspace-level) unlike the get_calls example which mentions filtering scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives, no prerequisites mentioned, and no warning about cascading effects. With 100+ sibling tools operating on related resources (folders, tasks, spaces), no guidance on deletion implications or order of operations is provided. The description gives zero context about when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. For a read operation, 'Get details' implies non-destructive behavior, which is reasonable. However, it doesn't disclose what fields are returned, whether additional permissions are required beyond basic workspace access, or what happens if the guest doesn't exist. The safety profile is implied but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the core purpose with zero wasted words. It's appropriately sized for a straightforward lookup tool. Could potentially add sibling differentiation, but the brevity itself is a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter get/read operation with 100% schema coverage, the description is mostly adequate. However, it lacks context about the relationship between guest and workspace roles, what information is retrievable for guests, and doesn't clarify behavioral expectations. Given it's a simple read tool, the missing context isn't critical but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (team_id and guest_id) are already documented in the schema with clear descriptions. The description adds no additional meaning beyond what the schema provides for the parameters. Baseline 3 is appropriate since the schema handles parameter documentation well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a guest user in a workspace' clearly states the verb (Get), resource (guest user), and scope (in a workspace). It distinguishes itself from sibling tools like get_workspace_members and get_authorized_user by specifying 'guest user' specifically. However, it doesn't name alternative sibling tools for comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. With siblings like get_workspace_members, get_authorized_user, and invite_guest_to_workspace, a user could benefit from knowing this is specifically for retrieving a single guest's details rather than listing members or managing guests. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get details' implies a read-only operation but doesn't explicitly state the safety profile or describe what fields/details are returned in the response. As a simple retrieval operation with a single parameter, the lack of behavioral nuance is somewhat acceptable, but there's no mention of error cases (e.g., invalid view_id) or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's appropriately sized for a simple retrieval tool. It could arguably mention return values but for a one-parameter get operation, this level of brevity is well-suited.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward single-parameter get operation with 100% schema coverage and no output schema, the description is minimally viable. It correctly identifies the action and resource. However, it doesn't clarify what 'details' means, whether the returned view includes tasks or metadata, or the relationship to the broader view/workspace hierarchy. Given low complexity, it's adequate but lacks clarifying depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (view_id), and the schema itself documents it as 'The view ID'. The description adds no parameter detail beyond what the schema provides. Since the baseline is 3 for high coverage and the description doesn't contradict or enhance the schema, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get details of a specific view' uses a specific verb (get) and resource (view), clearly indicating it retrieves detailed information about a single view. It distinguishes from sibling tools like get_list_views, get_workspace_views, get_space_views, and get_folder_views which retrieve collections, though the sibling differentiation is implicit rather than explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of needing a view_id from prior queries, no differentiation from get_view_tasks or the various list-views tools, and no exclusions or context about relationship to parent objects (workspace/space/folder views).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not disclose that this is a mutation (rename/reorder) operation, whether changes are reversible or partially applied (e.g., if renaming succeeds but reordering fails), what happens to name when omitted, or required permissions. It also doesn't mention behavior when partial parameters are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with zero wasted words. Front-loading is good: the verb actions come first. It's minimally sized but could arguably add one clause about partial-update behavior without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 params, 67% schema coverage, and no annotations or output schema, the description is thin. Mutation tools without annotations typically need more behavioral context (permissions, partial-update semantics, failure modes). Sibling tools like create_checklist and update_checklist_item exist, so clarifying the checklist vs item scoping would improve completeness. It's adequate but not robust for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (2 of 3 params have descriptions: name has none, position has context about 0-indexing, checklist_id is self-explanatory). The description adds value by clarifying that name relates to renaming and position to reordering, which aligns with the schema. However, it doesn't clarify whether name is optional and independent from position, or whether providing both is expected. Baseline 3 is appropriate given moderate schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Rename or reorder a checklist' uses specific verbs (rename, reorder) tied to a clear resource (checklist), immediately distinguishing it from sibling tools like create_checklist, delete_checklist, and update_checklist_item. The scope of what the tool does is immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as update_checklist_item (which handles items within a checklist) or create_checklist/delete_checklist. There are no exclusions or context clues about prerequisites, such as whether the checklist must already exist on a task. The agent must infer usage from the name and description context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. 'Create' implies a mutation, but the description doesn't disclose side effects, required permissions, uniqueness constraints, or what happens if the space doesn't exist. Given the tool creates resources and there are zero annotations, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single efficient sentence that conveys the core purpose with zero waste. The parenthetical clarifying the folderless nature is valuable and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 7 params, no output schema, and no annotations, a one-sentence description is thin. It doesn't explain return behavior, required permissions, or any constraints. However, the core purpose is clear and the required fields match the schema, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% (2 of 7 parameters described: name and space_id). The description doesn't elaborate on any parameters beyond implicitly referencing space_id ('in a space') and name ('create a list'). The 5 undocumented parameters (status, content, assignee, due_date, priority) receive no help from description. With low coverage, description should compensate but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Create a new list directly in a space (no folder)' — this is a specific verb+resource and the parenthetical clarifies the distinguishing trait from create_list or create_folder. It clearly states the 'no folder' scope, though it doesn't explicitly name the sibling alternative (create_list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is for creating a list that is NOT inside a folder, which distinguishes it from create_list for lists within folders. However, it doesn't explicitly state when to choose this over create_list, and the sibling 'create_list' exists without clarification of the difference beyond the implicit folderless context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the key behavioral qualifier (folderless/directly in space) but does not reveal return format, pagination, ordering, or whether archived lists are included by default. The archived parameter hints at filtering but behavior isn't stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and wastes no words. It conveys purpose and scope efficiently. It's slightly under-specified but this is acceptable for a straightforward list-retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read tool with only 2 parameters and no output schema. The description covers the core scoping behavior adequately, but given no annotations, it could specify a bit more (default archived behavior, result form). It's minimally complete for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 50% schema description coverage, the description needs to compensate. It adds semantic value by explaining that the result set is scoped to a specific space (space_id context), and the 'not in any folder' qualifier gives meaning beyond the raw schema. However, the 'archived' parameter's semantics are left to the schema's minimal type info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Get all lists') and adds a clear scope qualifier ('not in any folder, directly in a space'). This distinguishes it well from sibling tools like get_lists and get_folders, making the purpose clear and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description makes the scoping obvious (folderless lists in a space), it provides no explicit guidance on when to use this over alternatives like get_lists (which returns lists generally) or create_folderless_list. No exclusions or alternative tool mentions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It's a read operation (safe, non-destructive), but the description doesn't state what happens if no timer is running — does it return null, empty, or error? It also doesn't disclose whether the assignee parameter requires special permissions to query another user's timer. For a low-context tool with no annotations, more behavioral context 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a clean, single sentence that fully captures the tool's purpose with zero wasted words. It's appropriately front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read tool with good schema coverage (100%) and no output schema requirement. However, given there are no annotations, the description should clarify the no-running-timer behavior and assignee permission implications to be fully complete. It's adequate for a simple read operation but leaves important edge-case behavior unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the schema already documents both parameters (team_id and assignee) with their meanings. The description adds 'for the authenticated user' which clarifies the default behavior when assignee is omitted, but the assignee parameter's semantics of overriding that default is only inferable from the schema, not the description. Baseline 3 is appropriate since the schema covers the parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the currently running timer for the authenticated user' clearly states the verb (get), resource (currently running timer), and scope (authenticated user). It's distinct from stop_timer and start_timer siblings, though there's some minor overlap with get_time_entry and get_time_entries that it doesn't explicitly differentiate from.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it returns the user's active running timer, and the assignee parameter hints it can query another user's timer. However, there's no explicit guidance on when to use this vs. get_time_entries, or whether this requires an active timer to exist. The usage context is implied but not clearly delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It describes a read operation but doesn't state behavior around the 'archived' parameter (e.g., whether archived spaces are excluded by default), pagination, or what fields are returned. Lacks disclosure of likely destructive/side-effect-free nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, zero waste. Every word earns its place and the description is appropriately minimal for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple filtered-list read operation with full schema coverage and no output schema, this is reasonably complete. However, it doesn't address whether archived is default-excluded or explain return structure, which are minor gaps for a list-returning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (team_id as required workspace ID, archived as boolean to include archived spaces). The description adds no further param meaning, but the schema already handles the heavy lifting, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('get') + resource ('spaces') + scope ('in a workspace'). Distinguishes well from siblings like get_workspace, get_folders, get_lists, and get_space (singular form). Purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage context from the tool name and siblings (retrieves all spaces within a team), but no explicit statement of when to use this vs the singular get_space or when filtering might be needed. No alternative tool named explicitly, though get_space is an obvious sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. However, it only states that it retrieves views without revealing behavior such as whether it returns paginated results, whether the returned views include nested task data, permission requirements (who can call this), or ordering/filtering behavior. For a read operation with an absent annotation layer, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states exactly what the tool does with no wasted words or redundancy. It's appropriately minimal for a simple parameter-free-to-describe read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read tool with 1 parameter, 100% schema coverage, and no output schema. The description adequately conveys the operation. However, with no annotations and no output schema, a bit more detail about the return payload shape (what fields each view contains) or behavior could improve completeness. The low complexity keeps this at a minimum-viable 3 rather than lower.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single parameter space_id is fully documented in the schema. The description adds no additional param meaning beyond the schema, which aligns with the baseline of 3 when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all views for a space' has a specific verb (get) + resource (views) + scope (space). It's clear and distinguishes from siblings like get_workspace_views, get_folder_views, and get_list_views by specifying the space scope. Notably, there's no 'views' concept described beyond this tool, though siblings include get_view and get_space.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving views in a space context but provides no explicit when-to-use guidance or exclusion of alternatives. It doesn't mention that get_workspace_views, get_folder_views, or get_list_views might be more appropriate in other contexts, nor does it contrast this tool against them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether views are returned at a flat level, whether filtering applies, what happens for empty workspaces, permissions required, or pagination limits. For a list retrieval tool with zero annotation coverage, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the purpose and scope. Zero wasted words. While it is minimal, it front-loads the core information clearly, though it could be more informative about usage without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple single-parameter read tool with a fully documented schema. The description adequately identifies what is retrieved and at what level. However, without annotations or output schema, the description could benefit from noting that this returns Everything-level (top-level) views specifically rather than views nested within spaces or folders.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the sole parameter team_id is fully described in the schema ('The workspace/team ID'). The description adds the 'Everything level' context which clarifies the scope of what is being retrieved. With one fully-documented parameter and a single tool parameter at baseline 3, the description's scope qualifier slightly elevates this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all views for a workspace (Everything level)' uses a specific verb+resource combination and adds the scope qualifier '(Everything level)' which distinguishes it from the sibling get_space_views and get_folder_views. The purpose is clear and identifies the resource at the workspace level versus other nested levels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool retrieves views at the workspace scope, and the '(Everything level)' qualifier hints at the distinction from nested view tools. However, it does not explicitly state when to use this versus get_space_views or get_folder_views, leaving the differentiation to be inferred from the sibling names rather than clearly explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries the full burden. 'Move' implies mutation and possibly removal from the source list, but the description doesn't clarify whether the task is removed from its original list, whether any per-list custom field values are lost, or what the return behavior is. Adequate baseline but lacks behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that fully communicates the core operation. Zero waste, appropriately terse for a simple two-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool with no annotations and no output schema, the description is unusually sparse. It's functional but doesn't communicate the side effect of the move (removal from source list), which is the most important behavior the agent should understand. Adequate but could provide more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% - both list_id and task_id are described in the schema. The description adds no additional parameter context beyond what the schema already provides, which is the baseline 3. No explanation of relationship between task and list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource+action: 'Move a task to a different list' specifies the operation and its subject. However, it doesn't differentiate from siblings that also operate on tasks (e.g., update_task, duplicate_task), though it's distinct enough from tag/watcher/comment tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like update_task (which could also change list assignment) or duplicate_task. No context about cross-workspace restrictions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'remove a link' without noting whether this is reversible, whether it affects notifications, whether permissions are required, or whether linked tasks get affected. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that is front-loaded with the action verb and resource. Zero waste. While sparse, it earns its length for a straightforward 2-parameter operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-param, no-output-schema mutation tool, this is mostly adequate but could add context about the link relationship semantics and whether this is a hard/soft delete. The presence of both add_task_link and delete_task_dependency as siblings suggests link types exist that aren't clarified here. Minimal but sufficient for the simplest reading.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters have descriptions (task_id as Source task ID, links_to as Target task ID to unlink). The description and schema together convey the directional nature of removal, so the baseline 3 is elevated because the parameter naming plus descriptions clarify which is source vs target. Not much more needed for a 2-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a link between two tasks' has a specific verb (remove) plus resource (task link) and clearly states the action. It distinguishes itself from sibling add_task_link by the verb. However, it doesn't elaborate on what kind of link (dependency vs. generic), and doesn't explicitly differentiate from remove_tag_from_task or delete_task_dependency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what occurs (removing a link between two tasks) but provides no guidance on when to use it versus the sibling delete_task_dependency or add_task_link. No use cases, no exclusions, and no alternatives are named. Context is clear but there's no differentiation guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The description states it lists workspaces the 'authenticated user belongs to', which implies a read-only, user-scoped operation. However, it doesn't disclose return format, whether it includes guest memberships, or any auth requirements beyond authentication. It also doesn't clarify potential pagination or ordering behavior. Decent context on scope but lacks richness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with zero wasted words. It names the action (list), the resource (workspaces), adds a clarifying parenthetical (teams), and specifies the scope (authenticated user belongs to). Perfectly proportionate to the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with no output schema and no annotations, the description is reasonably complete. It clearly identifies what it returns (workspaces the user belongs to) and the auth assumption. Given the tool's low complexity, the description handles the essentials. Could note whether inactive/archived workspaces are included, but this is a minor gap for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters which code to 100% schema coverage, so the baseline is 4. The description confirms no parameters are needed, which is self-evident from the empty schema. The description adds minimal value here since there's nothing to explain. The 'belongs to' scoping is the only semantic addition beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'List all workspaces (teams) the authenticated user belongs to' with a clear verb (list), resource (workspaces), and scope (authenticated user's memberships). This distinguishes it from siblings like get_workspace (singular), get_workspace_members, and get_workspace_plan, which are distinctly different. It doesn't explicitly contrast against siblings but the plural form and scope make the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives. The description implies 'to list the user's workspaces' but doesn't explicitly address when to use get_workspace (singular) vs this tool, or how it relates to get_workspace_members. The context is clear from the purpose but lacks explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly states this is a removal/clearing operation (implying mutation), but doesn't describe what happens to the field or task after removal, whether it's reversible, or what the response contains. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence with zero waste. Every word earns its place and the dual verb phrasing (remove/clear) clarifies intent without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation tool with full schema coverage but no annotations and no output schema, the description is functional but minimal. It could benefit from stating the operation is destructive/non-reversible or clarifying that cleared fields revert to default. Adequate for simple usage but lacks depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% - both task_id and field_id are described in the schema. The description adds no additional parameter context beyond what the schema provides, so baseline 3 is appropriate since schema handles the documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove/clear the value of a custom field on a task' uses a clear verb (remove/clear) with a specific resource (custom field value on a task). It clearly distinguishes from its sibling set_custom_field_value which does the opposite operation, so sibling differentiation is implicit but functional.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use guidance or exclusions. However, the naming symmetry with set_custom_field_value and add/remove sibling pairs in the list makes the context reasonably clear. No alternatives are explicitly named or contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of safety disclosure. As a mutation (removal), it's implied that this modifies state, but the description doesn't note whether this requires specific permissions, whether it's reversible via add_task_watcher, or what the response looks like. For a simple operation, bare minimum is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no redundant or filler content. Every word earns its place. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation with no output schema and no annotations, this is adequate but minimal. The description clearly states the operation and the schema documents parameters fully. However, it could benefit from noting what the watcher concept means, what happens on failure, or confirming reversibility. For its simplicity, it meets the minimum viable bar.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the schema already documents both parameters (task_id as 'The task ID' and watcher_id as 'User ID to remove'). The description adds no additional semantics beyond the schema. Baseline 3 is correct when the schema carries all the documentation weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a watcher from a task' uses a clear verb (Remove) with a specific resource (watcher) and target (task). It distinguishes from sibling add_task_watcher and get_task_watchers clearly. However, it doesn't explicitly state the scope beyond the basic operation, so it doesn't fully differentiate from other watcher-related tools beyond the obvious opposite operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (removing a watcher so they stop receiving notifications), but provides no explicit when-to-use guidance or exclusions. There are alternatives in siblings (add_task_watcher, get_task_watchers) whose relationship is obvious but not stated. It relies on the agent inferring appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It's a read-only retrieval operation ('Get details'), which is implied by the verb. However, it doesn't disclose what fields the returned details contain, whether team_id must reference an existing workspace or behavior on invalid ID, or any permission requirements. For a simple read/get tool with zero annotations, the description adds minimal behavioral context but doesn't fully explain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, zero waste, directly states what it does. Appropriately minimal for a simple single-parameter get tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, full schema coverage, no output schema, and no annotations. For such a simple retrieval operation, the description covers the essential ground: what it gets and how it's scoped. There's no output schema to explain return values, so that burden isn't present. It's complete for the complexity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single team_id parameter described as 'The workspace/team ID'. This description adds the minor detail that this specifies the workspace to retrieve. Given full schema coverage and only one parameter, the baseline of 3 is appropriate; there's little for the description to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets details of a specific workspace, scoped by team ID. This is clear and specific (verb=get, resource=workspace, qualifier='by team ID'). It differentiates from siblings like get_workspaces (plural/listing) and get_workspace_members. However, it doesn't explicitly name the sibling for differentiation, so not a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching a single workspace's details, contrasting with get_workspaces (list all). The context of 'specific workspace by team ID' implies a targeted retrieval use case, but there are no explicit when-to-use or exclusions stated. The absence of a when-not-to-use or alternative naming keeps this at a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Get' implies a read operation with no destructive side effects. However, it doesn't disclose what profile fields are returned, whether auth failures have specific behaviors, or if there are rate limits. For a zero-parameter read tool, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that fully and accurately describes the tool's purpose. Zero waste, perfectly scoped. Front-loaded with the verb immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read operation with no output schema, the description is essentially complete. It tells the agent exactly what this does. The only minor gap is not describing the shape of the returned profile, but without an output schema that's a reasonable omission for such a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so there is nothing for the description to explain. The baseline for 0 parameters is 4. The description correctly indicates no parameters are needed by not mentioning any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the currently authenticated user's profile' clearly states the verb (get) and the resource (currently authenticated user's profile). It's specific and unambiguous. It doesn't distinguish from siblings, but among ~140 sibling tools this is fairly unique since none others reference the authenticated user directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context - this retrieves the profile of the logged-in user. It doesn't explicitly state when to use this vs alternatives, but there are no obvious alternative tools that serve this same purpose. The context is clear enough that an agent would understand when to call this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MohanadAlrefaai/clickup-mcp'

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