@illodev/taiga-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Every tool follows a systematic '<resource>_<action>' pattern, and each targets a distinct resource and operation. Even with 236 tools, the names and descriptions make the purpose of each tool clear, minimizing the risk of misselection.
Naming Consistency5/5
All tool names are consistently lowercase snake_case with the 'taiga_' prefix, followed by resource and action. The pattern is remarkably uniform across all resources, with only trivial deviations like 'get_by_slug' and 'related_userstories_list' that still follow the overall convention.
Tool Count1/5
With 236 tools, this server is far beyond even the 'too many' threshold of 25+, let alone the extreme 50+. While it covers a wide API surface, the sheer number is overwhelming for an agent and significantly impairs usability, making it an extreme mismatch for typical MCP server scope.
Completeness4/5
The tool set provides comprehensive CRUD and lifecycle coverage for major Taiga entities (projects, epics, user stories, tasks, issues, milestones, wiki, etc.). Minor gaps exist, such as no create/delete operations for attachments, no history/comments for epics and milestones, and no attachment writes, but these are relatively small compared to the overall coverage.
Average 3.1/5 across 236 of 236 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 25, 2026
- 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.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits, but it only says 'Watch a wiki page.' It fails to mention side effects (creating a subscription), what the response contains, or any required authentication. The tool's mutating nature is implied but not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single terse sentence, but it borders on under-specification rather than conciseness. It essentially restates the tool name and provides no additional information to the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, this description is severely incomplete. It does not explain the watch operation's consequences, reversibility, or expected response, making it inadequate for an agent to select and invoke 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?
The input schema already provides 100% coverage with a single parameter 'id' described as 'Wiki page ID'. The description adds no additional meaning beyond the schema, so it meets the baseline but offers no extra 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 states the action 'Watch' and the resource 'a wiki page', but it does not define what 'watch' means in this context (e.g., subscribing to notifications). It also does not distinguish this tool from sibling wiki tools like taiga_wiki_watchers or the watch tools for other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, no prerequisites such as authentication or permissions, and no mention of when to prefer alternatives like taiga_wiki_unwatch.
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 must disclose side effects and behavior. It only states 'Create a new issue types,' which is a minimal indication of a write operation but adds no details about permissions, response, duplicate handling, or any other behavioral traits. The description carries no burden beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence but is under-specified. It repeats the function name and does not include valuable information. The brevity is not efficient communication; it lacks necessary 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?
The tool is a create operation with 5 parameters, no annotations, and no output schema. The description gives no context about the creation process, required fields (beyond schema), return values, or project association. It is not self-sufficient for an agent to safely invoke the tool.
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 input schema describes 60% of parameters (name, color, project have descriptions; order and is_closed do not). The description adds no parameter information at all. Since coverage is only moderate and the description does not compensate, the parameter semantics remain incomplete.
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 'Create a new issue types' is essentially a restatement of the function name 'taiga_issue_types_create'. It provides no additional meaning and has a slight grammatical issue (plural 'types' for a single entity). It fails to distinguish from sibling tools beyond what the name already conveys, so it scores 2.
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, prerequisites, or alternatives. It does not mention that a project is required or that other operation tools (e.g., update, delete) exist for issue types. The description provides no context for tool selection.
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, the description must disclose behavioral traits. It only states the deletion action, with no mention of irreversibility, required permissions, side effects, or return values. This is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four words and fails to provide necessary information. It is under-specified rather than appropriately concise, and the awkward phrasing reduces 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?
The tool has one parameter and no output schema, but the description still lacks essential context such as the meaning of points, any prerequisites, or what happens upon deletion. The agent is left without guidance for a destructive action.
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 covers the single 'id' parameter with a minimal description 'ID'. The tool description adds no further semantic meaning. Per the baseline for high schema coverage, a score of 3 is appropriate, though the parameter description itself is extremely sparse.
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 'Delete a points.' merely restates the tool name 'taiga_points_delete' (delete + points). It adds no additional scope, context, or distinction from sibling tools, and the phrasing is grammatically awkward. This is effectively a tautology.
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, prerequisites, or alternatives. The description gives no context beyond the action itself.
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 disclosing behavioral traits. It only states 'Delete a priorities,' which tells the agent it is a deletion but fails to mention permanence, impact on associated data, required permissions, or error conditions. For a destructive operation, this is a significant disclosure gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only four words long, but this is under-specification rather than effective conciseness. The sentence is redundant with the tool name and does not earn its place by adding any 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?
For a simple delete tool with one parameter, a complete description should at least note that the action is irreversible or that the ID must reference an existing priority. No such context is provided. The description is minimally adequate but leaves the agent without operational clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter, id, described simply as 'ID,' achieving 100% schema description coverage. Since the description adds no parameter-specific information, the baseline score of 3 applies because the schema fully documents the parameter.
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 'Delete a priorities' merely restates the tool name 'taiga_priorities_delete' with a grammatical error. It is a tautology, providing no additional specificity about the action or resource beyond what the name already conveys.
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, whether there are prerequisites, or what alternatives exist. The sibling list includes many priority-related operations (list, create, get, update, bulk_update_order), but no attempt is made to differentiate this delete tool or explain appropriate usage contexts.
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 must carry the burden of disclosing side effects, permissions, or response behavior. It only says 'create', implying mutation, but gives no details about required project context, possible errors, or output. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. The sentence is grammatically awkward ('a new priorities') and provides almost no useful content, so it does not earn its place in a helpful way.
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 create operation with 5 parameters and no output schema, yet the description gives no context about priorities, project association, or typical usage. It is incomplete even for a simple CRUD tool, especially with no annotations to supplement it.
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%, meaning 'order' and 'is_closed' lack descriptions. The tool description adds no parameter explanations or guidance on how required parameters (project, name) interact. It fails to compensate for the undocumented parameters, providing no value beyond 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 'Create a new priorities' clearly states the verb (create) and resource (priorities), but it is essentially a restatement of the tool name. It lacks detail about what a priority is in Taiga or how this creation differs from other entity creation tools, making it vague and minimally informative.
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 prerequisites (e.g., project existence), and no mention of related tools like taiga_priorities_list or taiga_priorities_update. The description provides zero contextual 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?
With no annotations provided, the description carries the full burden of behavioral transparency. It only states that the tool creates a user story, but fails to disclose return values, side effects (e.g., creation of associated objects), permission requirements, or error behavior. For a mutation tool, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise in length, but it is under-specified for a tool with 18 parameters. It provides no additional value beyond the tool name and does not earn its place. The brevity here is a symptom of incompleteness, not effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (18 parameters, no annotations, no output schema), the description is completely inadequate. It does not explain required fields (project, subject), what the response contains, or any operational caveats. The agent would have little context to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is only 28% (5 of 18 parameters have descriptions), and the tool description mentions no parameters at all. It does not compensate for the low schema coverage, leaving the semantics of 13 parameters undocumented both in the schema and description. This is a serious deficiency.
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 ('Create a new user story') with a specific verb and resource. It does not explicitly differentiate from sibling create tools (e.g., taiga_tasks_create), but the resource type 'user story' is unambiguous. The statement is a near-tautology of the tool name but adds a human-readable phrasing.
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, nor does it mention prerequisites such as an existing project or required parameters. Usage is merely implied by the verb 'create', which is insufficient for an 18-parameter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure, but it only restates the action. It fails to disclose that watching is a state-changing operation, likely requires authentication, and may have idempotent or repeatable behavior.
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 very short and front-loaded, but it is under-specified to the point of nearly restating the tool name. It is concise, but the brevity sacrifices the substance needed to be a useful 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?
For a mutation-like tool with no annotations and no output schema, the description should explain the side effect of watching, any prerequisites, and its relationship to the watch/unwatch/watchers siblings. It provides none of this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter `id` is fully documented in the schema as 'User Story ID' (100% coverage), so the description does not need to add parameter meaning. It adds no extra semantic context, but the schema already covers it.
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 identifies the verb 'watch' and the resource 'user story,' but the meaning of 'watch' is ambiguous (view vs. subscribe) and it does not differentiate from sibling tools like taiga_userstories_get or taiga_userstories_unwatch.
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, when not to, or what alternatives exist. It does not mention that watch/unwatch/watchers form a related set or that it adds the user to the user story's watcher list.
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. It only states that it gets history but does not disclose what the history includes (e.g., diff, timestamps, user info), pagination, ordering, or any side effects. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It lacks essential details, so this is under-specification rather than appropriate conciseness. It does not front-load any additional value beyond the basic function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is incomplete. It does not explain what a 'change history' contains, how results are ordered, or any behavioral nuances. For a simple one-parameter tool, this is insufficient for an agent to use it confidently.
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 'id' that has its own description ('userstory ID'). The tool description adds no extra meaning, but the schema already provides sufficient semantics for the 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 change history for a userstory' clearly identifies the verb (get) and resource (change history for a userstory). It is distinct from sibling tools like taiga_task_history and taiga_issue_history by specifying 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 Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It only restates the basic function.
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 only hints at partial update semantics, but does not mention required permissions, reversibility of changes, or what happens to fields not specified in the request.
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 brief and front-loaded with a verb, but the grammar is awkward ('a userstory statuses') and it omits critical information. It is concise but not well-structured for maximum comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, no annotations, and dozens of sibling tools, this single-phrase description is grossly inadequate. It does not explain return values, required permissions, or how partial update behaves in practice, leaving the agent without enough context to invoke the tool 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 20% (only 'id' is described). The description adds no parameter-level meaning; 'partial' vaguely implies that fields are optional, but the schema already shows id as required while others are optional. It does not clarify the meaning or acceptable values for name, color, order, or is_closed.
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 userstory statuses (partial)' essentially restates the tool name's verb and resource, adding only 'partial' as a qualifier. It does not clarify what a userstory status is or distinguish this update tool from the many other status update tools in the sibling list, though it does indicate an update 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 like taiga_userstory_statuses_list, taiga_task_statuses_update, or other update operations. The description lacks any context about prerequisites, typical use cases, 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?
The description only mentions 'partial' without explaining what happens to unspecified fields, whether the update is idempotent, or any side effects. With no annotations, the description carries the full burden and fails to disclose mutation behavior or required authorization.
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, but this conciseness comes at the expense of clarity; the phrase 'a issue statuses' is grammatically incorrect. It does not waste words, but the content is too sparse to be effective.
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 no output schema and no annotations, this description is severely incomplete. It fails to specify the required id parameter, which fields are updatable, how partial updates behave, or what response to expect. For a mutation tool, this is a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'id' has a description), and the tool description does not mention or explain any parameters. The meanings of 'name', 'color', 'order', and 'is_closed' are not provided, leaving the agent to guess.
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 verb 'update' and the resource 'issue statuses', which clearly identifies the tool's action and target. The term '(partial)' hints at partial update but is vague and grammatically awkward. It is distinguishable from sibling update tools by the explicit 'issue statuses' resource.
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 taiga_issue_statuses_create or update tools for other status types. The description gives no context about use cases, 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?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses that the update is partial, which is useful, but it omits critical behaviors: that 'version' is required for optimistic concurrency checking, that missing fields are left unchanged, error conditions, and any authentication or permission requirements. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no wasted words. However, it is under-specifying for a tool with 14 parameters and no other documentation. While brevity is positive, it sacrifices necessary content, making it merely minimally acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 14 parameters, no annotations, no output schema, and no guidance on usage, the description is completely inadequate. It fails to explain the required 'version' parameter, the partial update semantics, or any behavioral context needed by an agent to use the tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only 'id' and 'version' have descriptions). The description adds no information about any of the 12 undocumented parameters (e.g., 'status', 'priority', 'subject'), and does not compensate for the schema gaps. The word 'partial' implies only provided fields are updated, but it doesn't explain any parameter meaning.
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 operation: 'Update an issue (partial).' The verb 'Update' and resource 'issue' are unambiguous, and '(partial)' clarifies that this is a partial/field-wise update rather than a full replacement. It does not explicitly distinguish from sibling update tools, but the tool name already identifies 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 information is provided about when to use this tool versus alternatives. It does not mention that for full updates or for other resources (epics, tasks, user stories) one should use different tools, nor any prerequisites like the need to fetch the current version first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Watch an issue.' without mentioning side effects (e.g., adding the user as a watcher), authentication needs, or reversibility. It is essentially a restatement of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief and contains no fluff, but it is under-specified and essentially redundant with the tool name. It does not earn its place by adding value.
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?
Despite the tool having only one parameter and no output schema, the description is incomplete: it does not explain the effect of watching an issue, expected return, or when to use the tool. The bare statement is insufficient for an agent to act 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?
The input schema fully documents the single parameter (id) with a description 'Issue ID', and the tool description adds nothing beyond that. With 100% 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 uses a specific verb 'Watch' and resource 'issue', clearly indicating the action and target. However, it does not elaborate on what 'watch' means or distinguish it from sibling watch tools beyond the resource 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, prerequisites, or alternatives. The tool name implies it is for issues, but the description offers no explicit 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only repeats that it updates order. It does not mention permissions, side effects, validation behavior, or what the response contains.
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 filler, front-loaded and easy to parse. However, its brevity sacrifices explanatory value, preventing a perfect 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 mutation tool with no annotations and no output schema, the description is far too thin. It lacks any behavioral context, usage caveats, or return information, leaving the agent to rely solely on the name and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (project ID and array of [id, order] pairs), achieving 100% coverage. The description itself adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Bulk update order of priorities.' is a word-for-word restatement of the tool name, providing no new conceptual information. It identifies the verb and resource but does not distinguish itself from the many sibling bulk_update_order tools for other entities.
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 such as taiga_priorities_update or other bulk_update_order tools. There is no mention of context, prerequisites, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a mutation ('Create') but does not mention side effects, required permissions, or impact on existing data. There is no note about the return value or error conditions, leaving the agent blind to important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (four words) but under-specified rather than appropriately concise. The grammatical error and lack of structure (no param hints, no usage context) make it more a stub than an informative description. It front-loads the verb but sacrifices necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and no output schema, this description is completely inadequate. It provides no context about what 'severities' are, how they relate to projects, or what fields are required beyond the schema. An agent cannot reliably determine when to invoke this tool or what configuration is needed.
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 description adds no parameter semantics beyond the schema. While schema covers 60% of parameters (name, color, project have descriptions), the remaining 40% (order, is_closed) are undocumented in both schema and description. The description fails to compensate for the gap or clarify parameter relationships.
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 ('Create') and resource ('severities'), clearly identifying the action and distinguishing it from list/get/update/delete siblings. However, it lacks scope (e.g., project context) and has a grammatical error ('a new severities'), preventing a perfect score.
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. It does not mention prerequisites, relationship to other severity tools (e.g., update, delete), or when creating a severity is appropriate. The description only states what it does, not when to use it.
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 available, the description carries the full burden of behavioral disclosure. It states that the tool creates tasks in bulk, which is a basic behavior, but it does not explain required fields, the format of bulk_tasks, concurrency/side effects, or the return value. This is minimal disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concisely informative. It is essentially a fragment that repeats the tool name, providing no structural benefit or added context. A good description would be one or two sentences that add value beyond the name.
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 no annotations, no output schema, and five parameters (two required), the description is severely incomplete. It fails to mention that project_id and bulk_tasks are required, how the bulk input is formatted (though schema covers it), what response to expect, or any usage context. This is insufficient for an agent to correctly invoke 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 description coverage is 80%, so the schema already documents four of five parameters. The description adds no parameter-specific information. It does not clarify the meaning of 'bulk_tasks' beyond what the schema says ('Newline-separated task subjects'), and leaves status_id undocumented. Baseline of 3 applies due to high 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 'Bulk create tasks.' clearly names the action (create) and resource (tasks), but it adds little beyond the tool name itself. It does not specify what 'bulk' means in practice (e.g., newline-separated subjects) and does not distinguish from the sibling 'taiga_tasks_create' except through the word 'bulk.'
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 the single-task create tool. The description does not state prerequisites, typical scenarios, or exclusions. The word 'bulk' implies batch use, but there is no explicit guidance.
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?
There are no annotations, and the description does not disclose any behavioral traits such as side effects, idempotency, authentication requirements, or return values. It merely restates the tool name in sentence form, leaving the agent without information about what happens when a task is watched.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but it is under-specified rather than properly concise. It provides no additional detail beyond the tool's name, so it fails to earn its place as a useful description.
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?
The tool has no output schema and no annotations, so the description carries the full burden. It does not explain what 'watch' does, what the response will be, or any prerequisites, making it inadequate for an agent to understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter (id, a Task ID) with 100% coverage, so the description does not need to add parameter semantics. The description adds no extra meaning beyond the schema, which is acceptable given the high 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 uses the verb 'Watch' and the resource 'task', clearly identifying the action. It distinguishes from sibling tools like taiga_tasks_get or taiga_tasks_unwatch, though it doesn't elaborate on what 'watch' entails (e.g., subscribing to notifications).
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 taiga_tasks_unwatch or taiga_tasks_watchers. The description solely states the action without any contextual, conditional, or exclusionary 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. It only implies a read operation ('Get') but does not disclose what data is returned, whether permissions are needed, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a two-word fragment that is under-specified rather than concise. It lacks necessary detail to guide an agent, making it more an unhelpful truncation than a well-structured summary.
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?
Although the tool is simple with one parameter and no output schema, the description is too minimal to convey what 'user stats' means or how the result is structured. Sibling tools like taiga_users_get and taiga_projects_stats highlight the missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter (id, 'User ID'), achieving 100% schema description coverage. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Get') and resource ('user stats'), but 'stats' is vague and does not specify what statistics are included. It does not distinguish from sibling tools like taiga_users_get or taiga_projects_stats.
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, context, or why one would choose this over taiga_users_get or other stats 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?
With no annotations, the description carries the full burden of disclosing behavior, but 'Watch an epic' does not state that this is a state-changing operation, that it likely adds the current user as a watcher, whether permissions are required, or what the response looks like. The behavioral profile is essentially undisclosed.
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 very short and front-loaded, with no wasted words. However, it is under-specified to the point of being minimally informative, so while concise, it is not an appropriately sized description for a tool with no annotations or output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description should explain the effect, return value, and any prerequisites or side effects. 'Watch an epic' only names the action and resource, leaving an agent without enough context to predict the outcome or handle success/failure cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter 'id' as 'Epic ID' with 100% coverage, so the description adds no additional parameter semantics. The baseline of 3 applies because the schema is sufficient and the description does not need to compensate.
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 specifies a verb ('Watch') and a resource ('an epic'), so it is clear this action applies to epics. However, it is essentially a restatement of the tool name with no explanation of what 'watching' means in this context (e.g., subscribing to notifications), making it vague for an agent unfamiliar with Taiga terminology.
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 taiga_epics_unwatch, taiga_epics_watchers, or similar watch tools for other resource types. The description gives no context, prerequisites, or exclusions, so an agent cannot determine appropriate usage conditions.
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 present, so the description must carry the full burden of disclosure. It only states the action 'create' without revealing any side effects, permission requirements, or behavior on invalid input. This adds no information beyond what the tool name already implies.
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, 'Create a new task,' which is concise and front-loaded with the primary action. There is no wasted wording, but it lacks supporting context. It earns a high score for conciseness, though it's not as informative as the calibration example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with 13 parameters and no output schema or annotations, the description is far from complete. It doesn't mention what happens upon success, how the created task is identified, or what the required fields (project, subject) mean beyond the schema. The agent lacks critical context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 13 parameters and only 23% schema description coverage, the description offers no additional parameter semantics. The input schema has some descriptions for project, subject, and user_story, but the description does not compensate for the many undocumented fields like tags, status, watchers, is_closed, etc.
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 'Create a new task' uses a specific verb and resource, clearly distinguishing it from sibling create tools for epics, user stories, and issues. The name taiga_tasks_create reinforces the task resource, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 taiga_userstories_create or taiga_issues_create. It does not mention prerequisites such as the project existing, nor does it specify any conditions or exclusions for use.
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?
There are no annotations, and the description provides no behavioral context beyond the action 'create'. It does not disclose mutation risks, permission requirements, response behavior, or limits, which is essential for a write operation 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words, but it is under-specified. It is a single phrase that serves more as a label than an explanatory description, so it does not earn a higher score for structure.
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 bulk creation tool with no annotations or output schema, the description is minimally adequate. It conveys the operation and relies on the schema for parameters, but omits details about the newline-separated format, response behavior, and any side effects, making it incomplete for reliable invocation.
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 parameters documented. The description adds no additional parameter semantics, but the baseline of 3 applies because the schema already handles parameter meaning.
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 specific verb and resource ('Bulk create epics'), clearly indicating the operation. It implicitly distinguishes from sibling 'taiga_epics_create' by using 'bulk', though it does not 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 provided on when to use this tool versus alternatives like 'taiga_epics_create'. The word 'bulk' implies multiple epics, but there is no explicit context, 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 present, and the description only says 'create' without disclosing permissions, required fields, idempotency, or response behavior. The verb implies a destructive write operation, but no additional transparency 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it suffers from a grammatical issue and lacks any structural elements (e.g., prefix, bullet points) that would aid scanning. It is concise but under-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?
With no output schema, no annotations, and a description that only names the action, the agent lacks context about required inputs, side effects, or return value. This is insufficient for safe invocation of a mutation tool with five 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 coverage is 60%, and the description adds no parameter semantics beyond what the schema already provides. It does not explain the undocumented 'order' or 'is_closed' fields, nor does it reinforce that project and name are required.
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 clearly states an action (create) and a resource (issue statuses), and the 'issue' qualifier distinguishes it from sibling status creation tools (e.g., task statuses, user story statuses). However, the plural 'statuses' is grammatically awkward and could ambiguously imply creating multiple statuses at once, which is not clarified.
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?
Provides no guidance on when to use this tool versus alternatives. Does not mention that project and name are required, nor does it explain how this differs from listing, updating, or deleting issue statuses.
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 reveals that the update is partial but does not mention permissions, error handling, whether unspecified fields are preserved, or any side effects. This is a mutation tool with minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the verb and resource. It is not bloated, though the phrase 'a task statuses' has a grammatical issue and the brevity borders on under-specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low schema richness, no annotations, and no output schema, the description should provide more context about the purpose, required parameters, and behavior. It only says 'partial', which is insufficient for an agent to fully understand the tool's use and expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'id' has a description saying 'ID'). The description does not compensate; it does not explain that name, color, order, and is_closed are updatable fields or how they relate. The word 'partial' is the only hint, leaving the agent without meaningful parameter semantics.
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 the verb 'Update' with the resource 'task statuses' and notes 'partial', making it clear this is a partial update operation on an existing task status. This distinguishes it from create/list/get/delete siblings, though it does not explicitly contrast with the bulk update order tool.
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 taiga_task_statuses_create, taiga_task_statuses_delete, or the bulk update order variant. The word 'partial' implies updating only some fields, but there is no explicit context or exclusions.
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 says 'Get a specific user story attachment' with no mention of error behavior, required permissions, return format, or side effects. This is a significant gap for a fetch operation with no annotation support.
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, which is front-loaded and free of unnecessary words. However, it is so minimal that it adds little information beyond the tool name, making it under-specified rather than effectively 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?
The tool is simple with one parameter and no output schema, but the description provides almost no contextual information. It does not mention what the attachment represents, what response to expect, or any limitations. Given the lack of annotations and output schema, the description is incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter, id, described as 'Attachment ID,' providing 100% schema coverage. The description adds no extra meaning beyond the schema, so it relies entirely on structured data. With 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 clearly states the action ('Get') and the resource ('a specific user story attachment'), which distinguishes it from sibling attachment_get tools for other object types such as epics, tasks, or issues. It is a specific verb+resource pairing, though it lacks additional scope detail that could make it completely 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 on when to use this tool versus alternatives. With sibling tools like taiga_epics_attachment_get, taiga_tasks_attachment_get, and taiga_issues_attachment_get, the description would benefit from explicitly stating that this is for user story attachments only. The resource type is implied by the name, but usage context or exclusions are 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 the full burden of behavioral disclosure. It mentions 'optional filters' but does not disclose pagination, default limits, response structure, or any side effects, leaving significant behavioral traits unspecified.
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, front-loaded with the verb, and contains no filler. It is concise and for what it states, it is efficient, though it may be too sparse for full usefulness.
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 16 parameters, no annotations, and no output schema, the description is grossly inadequate. It provides no context on how the listing behaves, what fields are returned, how filters combine, or any other essential information for 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 63%, so the schema carries most of the parameter meaning. The description adds no specific parameter semantics; 'optional filters' is generic and does not help with the undocumented parameters such as exclude_role, exclude_tags, or status__is_closed.
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 tool lists user stories, using a specific verb and resource. It does not explicitly differentiate from sibling list tools for other entities, but the resource name in the tool name itself makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 such as taiga_userstories_get or taiga_userstories_get_by_ref. The description only states what it does, not when to choose it or when to prefer alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Create a new userstory statuses,' which implies a mutation but does not disclose required permissions, side effects, or the fact that it operates within a project context. This is a minimal disclosure of behavior.
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 very concise, consisting of one short sentence with no waste. However, it essentially restates the tool name and lacks substantive content, so it does not maximize the dimension of being appropriately sized 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?
For a create operation with 5 parameters, no annotations, and no output schema, the description is severely under-specified. It doesn't indicate required fields (project and name), what the created status represents, or what the response contains, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 60% of parameters with descriptions (name, color, project). The tool description adds no parameter information beyond the schema and doesn't clarify the meaning of 'order' or 'is_closed,' which lack schema descriptions. The description fails to compensate for the coverage gap.
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 identifies the action as 'Create' and the resource as 'userstory statuses,' providing a specific verb and object. However, it doesn't distinguish from sibling tools like taiga_task_statuses_create or taiga_issue_statuses_create, so it lacks sibling 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?
There is no guidance on when to use this tool versus alternatives. The description only says 'Create a new userstory statuses' without mentioning any prerequisites, exclusions, or differences from other status creation tools, leaving the agent without context for selection.
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. 'Partial' discloses PATCH-like behavior, but it fails to mention required ID, permission/auth needs, side effects, or response behavior—significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words, earning credit for conciseness. However, it is under-specified, providing only the bare action and partial-update signal without additional structured 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?
Given four parameters, low schema coverage, no annotations, and no output schema, a one-sentence description is insufficient for reliable tool selection and invocation. It lacks field semantics, usage conditions, and behavioral details, making it only minimally viable.
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 'id' has a description). The description adds no parameter-level detail for key, url, or name, failing to compensate for the sparse schema. The agent must infer semantics from parameter names alone.
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 ('Update') and resource ('webhook'), and 'partial' indicates PATCH semantics. This distinguishes it from sibling webhook tools like create, get, delete, and test, though it omits which 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?
No guidance is given on when to use this tool versus webhooks_create or webhooks_delete. It does not mention that an existing webhook ID is required or that this tool is for modifying existing webhooks rather than creating new ones.
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, the description carries the full burden of behavioral disclosure, but only states the verb 'update.' It does not explain whether the update is partial or full replacement, whether permissions are required, or what happens if the link does not exist.
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, concise sentence with no wasted words, but it is under-specified. While brevity is good, the lack of any additional structure or detail makes it nearly a tautology, providing only the action and resource without context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with 4 parameters, no output schema, and no annotations, the description is grossly inadequate. It fails to explain updatable fields, side effects, or response behavior, making it impossible for the agent to know what a successful invocation entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only 25% description coverage (only 'id' is described). The description 'Update a wiki link.' adds no explanation of the href, order, or title parameters, so the agent cannot determine their meaning, optionality, or allowed values.
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 'Update a wiki link.' uses a specific verb ('update') and resource ('wiki link'), clearly identifying the tool's purpose. It also implicitly distinguishes from sibling tools like taiga_wiki_update (updates a wiki page) and taiga_wiki_links_create/get/delete by focusing on the update action for wiki links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention taiga_wiki_links_create, taiga_wiki_links_delete, or taiga_wiki_update, and offers no context about prerequisites or scenarios where partial updates are needed.
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, the description carries the full burden of disclosing behavioral traits, but it merely restates the action 'Create a new issue.' It does not mention required permissions, side effects, error conditions, or any other behavioral context beyond the obvious write operation.
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 extraneous content, making it efficient and front-loaded. However, it is perhaps too terse for a tool with many parameters, though it does not contain wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (14 parameters), no annotations, and no output schema, this one-sentence description is inadequate. It omits required fields, parameter semantics, and expected return behavior, making it difficult for an agent to invoke the tool correctly in non-trivial scenarios.
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 14% (2 of 14 parameters have descriptions). The description does not compensate for the lack of parameter details, offering no explanation of fields like status, priority, or assigned_to. An agent must rely on the sparse schema without additional context.
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 the specific verb 'Create' and identifies the resource 'issue', which clearly distinguishes it from update/get/delete tools in the sibling list. However, it does not explicitly differentiate from taiga_issues_bulk_create, though 'new issue' implies a single issue.
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 taiga_issues_bulk_create or other create tools. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states 'Upvote an issue' without explaining the effect (e.g., creating a vote), idempotency, authentication requirements, reversibility via downvote, or the response shape. For a mutation action, this is a critical omission.
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 concise with zero filler words; it is a single, direct sentence. However, its brevity borders on under-specification, though that is not a conciseness issue per se. It earns its place as a clear statement of purpose, but lacks supporting details that would make it more useful.
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 simple (one param, no output schema), but the description leaves major gaps: no return value, no behavioral details, no mention of typical usage or error cases. Even for a single-action tool, an agent cannot infer whether the action requires authentication or what happens if the issue doesn't exist. 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?
The input schema already documents the single parameter 'id' as 'Issue ID' with 100% description coverage. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate. No extra context about the id's format or usage is provided.
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 'Upvote an issue' clearly identifies the action (upvote) and the resource (an issue). It is unambiguous and distinct from other resource-specific upvote tools by the resource name, though it does not explicitly contrast with sibling tools like downvote or voters. The verb+noun structure is specific enough to convey the tool's core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention taiga_issues_downvote, taiga_issues_voters, or any prerequisite like the issue must exist. There is no indication of context in which upvoting is appropriate, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions 'partial,' implying a non-destructive field-level update, but it does not disclose return format, required permissions, idempotency, or whether omitted fields are preserved. This is minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundancy, which is effective in terms of brevity. However, the phrase 'a issue types' is grammatically incorrect and the content is somewhat underspecified, though not as bad as a pure tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, and no annotations, this description is too thin to fully support invocation. It does not explain whether all fields are optional, what the response looks like, or any side effects. The agent is left to infer crucial behavioral 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 20% (only 'id' has a description). The description adds no detail about 'name,' 'color,' 'order,' or 'is_closed'—for instance, whether 'order' is a positional index or 'is_closed' marks the issue type as closed. It 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('issue types'), and the word 'partial' signals that not all fields are required. It distinguishes from siblings like taiga_issue_types_create and taiga_issue_types_delete, though the grammar 'a issue types' is slightly off.
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 is no mention that this is for modifying an existing issue type, or that create should be used for new records. The tool name implies the purpose, but the description provides no explicit 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'create', implying a mutation, but fails to mention required permissions, side effects, or what happens on successful creation. This lack of transparency is a significant gap for a tool that creates persistent data.
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 is appropriately front-loaded with the core action and resource. However, it is so minimal that it arguably under-specifies the tool's behavior, but for conciseness alone, it earns a high 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 tool with 8 parameters, 4 required, no output schema, and no annotations, this description is far too thin. It lacks any context about return values, required fields, error scenarios, or relationships to other entities. The description is insufficient for an agent to invoke the tool with confidence.
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 tool description adds no meaning beyond the input schema. Schema coverage is 63%, leaving parameters like slug, order, watchers, and disponibility undocumented in both schema and description. The description does not clarify any parameter values or relationships, so it fails to compensate for the coverage gap.
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 milestone/sprint' clearly states the action (create) and resource (milestone/sprint). It distinguishes from sibling tools like taiga_milestones_update and taiga_milestones_delete by specifying creation, but it doesn't explicitly differentiate from other create tools in the broader context. The verb and resource are specific enough for basic identification.
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, such as needing an existing project, or scenarios where another create tool might be more appropriate. The description simply states what it does without any contextual usage 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. However, 'Watch a milestone' does not explain what watching entails, such as whether it subscribes the current user, requires authentication, or has side effects. This minimal description leaves the agent without essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief, consisting of only 'Watch a milestone.' While concise, it is under-specified and essentially restates the tool name. It provides no additional helpful information, making it closer to a placeholder than a meaningful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is still incomplete. It fails to explain the concept of 'watching' in the Taiga context or how it differs from other watch-related tools. The agent lacks sufficient context to select and invoke this tool effectively without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'id' with description 'Milestone ID'. The tool description adds no additional parameter semantics beyond what the schema already provides. Baseline of 3 is appropriate given the high 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 'Watch a milestone' clearly identifies the action (watch) and the resource (milestone). It is a specific verb+resource construction, though it does not explicitly differentiate from sibling watch tools for other resources. The purpose is understandable for someone familiar with Taiga.
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 taiga_milestones_unwatch or taiga_milestones_watchers. It does not mention any prerequisites, context, or conditions for watching a milestone.
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, the description carries full responsibility for behavioral disclosure. It only says 'Create', implying mutation, but provides no details about required permissions, side effects, duplicate handling, or return value. Minimal value beyond the verb.
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, making it extremely concise and front-loaded. However, the awkward phrasing 'a new points' detracts slightly from 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?
The description is too thin for a create operation with five parameters and no output schema. It does not explain what a 'point' is in the Taiga domain, what fields are required beyond the schema, or what the API returns on success.
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 description adds no parameter context beyond the schema. Schema coverage is 60%, leaving 'order' and 'is_closed' undocumented, and the description does not compensate by explaining these or any other 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 clearly identifies a create operation for points, distinguishing it from sibling list/get/update/delete tools. The grammar is slightly awkward ('a new points') but the intent 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 usage guidance is provided. It does not indicate when to use this tool versus other point-related tools, nor any prerequisites like project membership or context for what points represent.
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 disclose behavior; it only says 'Update a points (partial)'. It does not mention required permissions, effects on unspecified fields, error handling, or response format. The partial modifier adds minimal transparency.
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 and front-loaded, but it is a grammatically awkward fragment ('a points') and omits useful context that could be added without bloat. It is concise but not well-constructed.
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 5 parameters, no output schema, and no annotations, yet the description provides no information about return values, side effects, required permissions, or field meanings. The single 'partial' hint is insufficient for an agent to invoke the tool safely and correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only the id parameter has a schema description ('ID'); name, color, order, and is_closed are undocumented. With schema description coverage at 20%, the description should compensate but instead names no parameters or expected formats. An agent cannot infer the meaning or constraints of the optional fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as an update to points, and the word 'partial' indicates PATCH-style modification. This differentiates it from sibling tools like taiga_points_create and taiga_points_delete, which perform different CRUD 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?
There is no guidance on when to use this tool instead of taiga_points_create or taiga_points_list, nor any mention of prerequisites or alternatives. The only hint is 'partial', which implies field-level updates but does not state a concrete use case.
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, and the description 'Like a project' discloses no behavioral details such as authentication requirements, idempotency, effect on project state, or reversibility. This is essentially a bare action with zero transparency.
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 concise, using only three words to state the core action. It front-loads the action effectively with no wasted words, though it borders on under-specification rather than polished brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description leaves out critical context such as required permissions, what response to expect, and whether liking is idempotent. A simple like action still needs this context to be fully usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single 'id' parameter, described as 'Project ID'. The tool description adds no extra semantic meaning, so it meets the baseline but does not go 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 'Like a project' uses a specific verb 'like' and resource 'project', making the primary action clear. It distinguishes from sibling tools like 'watch' or 'upvote' by its unique verb, but does not explicitly name alternatives, so it is clear 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?
There is no guidance on when to use this tool instead of similar ones such as taiga_projects_unlike or taiga_projects_watch. The description provides no context, exclusions, or preferences, leaving the agent to infer usage solely from the name.
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?
Annotations are absent, so the description must carry the full burden of behavioral disclosure. It only states 'List projects' and mentions filters, but does not disclose pagination behavior, default ordering, authentication requirements, or whether it returns all projects or only those accessible to the user. The read-only nature is implied but not explicit.
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 terse sentence that is easy to parse and front-loaded with the main action. There is no fluff, though the vague 'etc.' slightly reduces clarity without adding 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?
Given the tool has no annotations, no output schema, and 6 optional parameters, this description is too thin. It does not explain the output format, all filter semantics, or any caveats, leaving the agent with significant gaps when deciding whether and how to invoke it.
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?
With only 33% schema description coverage, the description needed to compensate by explaining parameters. It names only 'member' and 'is_featured' and then says 'etc.', leaving order_by, is_kanban_activated, is_backlog_activated, and is_looking_for_people unexplained. This is insufficient for a 6-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 uses a specific verb ('List') with the resource ('projects') and mentions optional filters, which clearly conveys the core action. It does not explicitly differentiate from sibling project tools like taiga_projects_get_by_slug or taiga_projects_stats, but the 'List' action strongly implies a collection-retrieval 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?
There is no guidance on when to use this tool versus its siblings such as taiga_projects_get, taiga_projects_create, or taiga_projects_stats. The phrase 'Optionally filter...' describes capability, not context, and no exclusions or alternative tools 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?
With no annotations, the description bears full responsibility for disclosing behavior. It only states the action and optional filters, without mentioning return format, pagination, default sorting, or any side effects. The read-only nature is implied but not explicitly confirmed.
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, tightly-worded sentence with no wasted words. It would benefit from a brief expansion to explain the listing scope, but it is structurally clean 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?
Given the tool's complexity (16 interchangeable filters, no output schema, no annotations), the description is severely under-specified. It does not explain whether a project scope is required, how results are paginated, or what fields are returned. This gap would leave an agent uncertain about invocation expectations.
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 56%, with many parameters lacking descriptions (e.g., order_by, exclude_*). The description's phrase 'optional filters' adds no semantic detail about how each filter behaves or which are mutually exclusive. The schema itself provides partial information, but the description fails to compensate for 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 uses a specific verb 'List' with a clear resource 'tasks', distinguishing it from sibling tools like taiga_epics_list or taiga_userstories_list. However, it lacks specifics about the listing scope (e.g., project-wide or global) and does not mention any constraints, so it is not fully self-contained.
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 taiga_tasks_get for single-task retrieval or taiga_userstories_list for user stories. The description gives no context on typical use cases 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Create', which implies mutation, but does not mention permissions, idempotency, validation, response format, or potential side effects. For a create operation, 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 sentence, extremely concise and front-loaded. However, it is grammatically awkward ('a new task statuses') and omits useful information, though this is a minor issue for conciseness scoring.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and no output schema, the description should explain key aspects like project association, meaning of order/is_closed, and response behavior. It provides none of this, making it incomplete for an agent to use confidently.
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 description adds no information about parameters, leaving the schema to explain them. Schema coverage is only 60%, with 'order' and 'is_closed' lacking descriptions. The description does not compensate for these gaps, so the agent must infer semantics from names and types alone.
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 'Create' and the resource 'task statuses', making the tool's purpose unambiguous. It differentiates from sibling status creation tools by explicitly naming 'task' rather than userstory or issue, though it does not provide any additional scope or contextual details.
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 prerequisites mentioned, and no reference to the many sibling tools. The description is a bare statement of functionality with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It merely restates the action without revealing that deletion is permanent, what happens to associated tasks, or whether special permissions are required. This is a significant gap for a destructive operation.
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 filler or unnecessary content, and the key verb is front-loaded. The minor grammar error does not detract from conciseness, though the content is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter, no output schema), the description is somewhat adequate, but the lack of annotations means it should warn about irreversibility or cascading effects. A bare 'Delete a task statuses' does not fully prepare an agent to invoke this destructive tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single 'id' parameter with 100% coverage and a description ('ID'). The tool description adds no further parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly uses the verb 'Delete' and identifies the resource as 'task statuses', which matches the tool name and distinguishes it from sibling list/create/get/update status tools. However, the grammar is awkward ('a task statuses'), which prevents a 5.
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, nor does it mention exclusions or prerequisites. It simply states the action, leaving the agent to infer suitability from the tool name and 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?
With no annotations, the description carries full burden for behavioral disclosure, but it only states the basic action. It does not explain what the timeline includes, how pagination works, what events are shown, or any response details, leaving significant behavioral ambiguity.
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 filler or repetition, making it efficient. However, it is so brief that it borders on under-specification rather than effective 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?
For a timeline tool with no output schema and no annotations, the description provides minimal context. It omits important details such as what a timeline contains, pagination behavior, or how it differs from similar timeline tools, making it incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (50%) with only user_id described as 'User ID'. The description adds no parameter information, leaving the 'page' parameter entirely undocumented. The tool description does not compensate for the missing schema descriptions.
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 timeline for a user' uses a clear verb and resource, and correctly identifies the tool's scope as being user-specific. However, it does not distinguish this from sibling tools like taiga_timeline_profile or taiga_timeline_project, so there is some ambiguity in 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 is no mention of prerequisites, context, or exclusions, leaving the agent without clear direction on choosing this over similar timeline 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?
With no annotations available, the description carries the full burden of behavioral disclosure. 'Partial' is a useful behavioral hint, but it fails to disclose that the 'version' field must match the latest version for optimistic concurrency control, or that this is a write operation that may fail. The schema documents 'version' as 'Current version for conflict check', but the description itself does not mention this critical behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely terse at five words, which is front-loaded but grossly under-specified for a tool with 13 parameters and a version-based conflict check. It functions more as a title than a functional description, lacking any structural explanation or additional context. Brevity here sacrifices 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?
Given the high complexity (13 parameters, many with no schema descriptions, no output schema, and no annotations), this description is completely inadequate. It fails to explain the partial update behavior thoroughly, the requirement for a version parameter, or what response to expect. An agent would have almost no understanding of how to invoke this tool 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 very low (15%), and the description does not compensate. It only hints that a subset of fields may be updated, but it does not explain any of the individual parameters beyond the property names. The description adds no meaning beyond what the schema already provides, leaving the agent to infer semantics for the 11 undocumented fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Update') and the resource ('user story'), and the word 'partial' defines the scope of the operation, distinguishing it from full-replace or bulk-update alternatives. This is a specific and unambiguous purpose statement that aligns with the tool name and differentiates it from sibling tools like taiga_userstories_get or taiga_userstories_delete.
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. It does not mention any prerequisites, the need for a version number, or contrast with other update-related tools such as bulk_update_backlog_order. The phrase 'partial' implies that only provided fields should be updated, but there is no explicit context about when this tool is preferred over alternatives.
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 only states that it updates a definition, omitting partial-update semantics, required id, authentication needs, effects, or response behavior. This is insufficient 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, front-loaded sentence with no filler, making it concise. However, it is under-specified for the tool's complexity, so it does not achieve a perfect 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 mutation tool with five parameters and no output schema, the description is too thin. It does not explain update semantics, required vs optional parameters, return values, or any constraints, leaving the agent without sufficient context beyond the tool's basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema parameter description coverage is only 20% (only 'id' has a description), and the description does not compensate by explaining any parameter. The optional fields (name, type, order, description) remain entirely unexplained, leaving the agent without meaningful semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('custom attribute definition') with scope ('for issue'), clearly distinguishing it from sibling tools for other entities (epic, userstory, task) and from value-update tools via the word 'definition'.
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 the values_update sibling or the custom attribute create/get/delete tools. The intended usage is implied only by the bare action statement.
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 disclosing behavioral traits. It only says 'Bulk update order of issue statuses,' which implies a mutation but does not mention permissions, whether the operation is reversible, what happens to unsorted statuses, or any potential side effects. This is comparable to the update_drive example where 'update' implied mutation but lacked crucial details.
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 concise sentence, which is easy to scan. However, it essentially restates the tool name without adding value or structure that helps an agent decide when to use it. It is appropriately short but lacks the informative substance of a well-crafted description.
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 bulk mutation tool operating on project-specific issue statuses, the description is under-specified. It does not explain the expected format or semantics of the 'order' values, whether the operation replaces all existing ordering, or how errors are handled. With no annotations and no output schema, the description should provide more context to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for both parameters: project (Project ID) and bulk_orders (Array of [id, order] pairs). Since schema coverage is 100%, the baseline is 3. The description adds no further semantic context about ordering conventions, indexing, or whether all statuses must be included in the array.
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: 'Bulk update order of issue statuses.' The verb 'update' and resource 'order of issue statuses' are specific and unambiguous. It distinguishes itself from sibling bulk_update_order tools by identifying the target resource (issue statuses), though it doesn't explicitly contrast with alternatives.
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 such as taiga_userstory_statuses_bulk_update_order or taiga_task_statuses_bulk_update_order. No context is provided about prerequisites, whether the user should first list statuses, or any scenario-based recommendations.
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?
The description discloses the key behavioral trait that updates are partial, meaning only provided fields are changed and omitted fields remain untouched. This is valuable beyond the schema. However, with no annotations, it does not mention permissions, return values, error behavior, or side effects, leaving several transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words, but it is under-specified for a tool with 5 parameters. It lacks structured information and contains a grammatical error, reducing clarity. It is brief but not ideally complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description must carry more weight. It only provides a minimal action statement and does not describe return values, error conditions, permissions, or the full scope of the update. This is insufficient for an agent to fully understand the tool's context.
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 'id' has a description). The description text does not compensate by explaining the meaning or format of the optional parameters (name, color, order, is_closed). The word 'partial' implies these are updatable fields, but adds no specific semantics.
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 action ('Update') and the resource ('priorities'), making it clear that this tool modifies an existing priority. The parenthetical '(partial)' indicates a partial update, which adds useful nuance. However, the grammar 'a priorities' is awkward and it does not list the updatable fields, so it is not as informative as it could be.
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 create, get, or delete. The verb 'update' implicitly suggests use for modifying existing records, but the description lacks explicit context, 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 present, so the description must fully disclose behavioral expectations. It only states 'Get,' which is a read operation, but does not discuss response format, error conditions, or any required permissions. This is minimal 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is very concise. However, it is grammatically incorrect and lacks any supplementary details. While every word earns its place, the message is under-specified yet not overly wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of an output schema, this description is insufficient. It does not explain what a severity is, what the return value contains, or when to use this endpoint. An agent would need to infer domain knowledge from the sibling 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?
The input schema has full coverage for the single 'id' parameter (description 'ID'). The tool description merely repeats the concept of filtering by ID without adding semantics about the value format, purpose, or how it relates to the severity object. Per the baseline for high schema coverage, a score 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 uses the verb 'Get' and identifies the resource as 'severities' with a lookup by ID. This clearly indicates a single-item retrieval operation. However, the grammar is awkward ('a severities') and it doesn't explicitly differentiate from the list tool, though 'by ID' implies that 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 versus alternatives like taiga_severities_list. There is no mention of prerequisites or exclusions, leaving the agent without explicit decision 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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Create' without mentioning side effects, permissions, validation rules, or uniqueness constraints. This is a significant gap for a write operation.
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. However, it is so minimal that it borders on under-specification, though it is not a tautology.
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 is incomplete for a create tool. It does not indicate what the tool returns, whether it requires special permissions, or any other operational context beyond the basic action.
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 description adds no parameter information beyond what the schema already provides. Schema coverage is 60%, leaving 'order' and 'description' undocumented, and the description does not compensate for these gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Create) and the specific resource (custom attribute definition for epic). It differentiates from sibling tools by specifying the entity type 'epic', which distinguishes it from custom attribute creates for user stories, tasks, and issues.
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, no prerequisites, and no mention of exclusions. Usage is only implied by the verb and resource name, not explicitly 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only listing operation, but does not disclose pagination, ordering, authentication needs, or the effect of leaving the project filter empty. It adds minimal behavioral detail beyond what the name/schema already imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences. Every word earns its place, with no filler or redundant restatement of the tool name. It is appropriately sized for a simple list operation.
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-parameter tool with no annotations and no output schema, the description is too sparse. It omits return value structure, pagination or ordering behavior, and whether filters are optional or combinable. It is minimal but leaves significant gaps for an AI agent.
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 67%, with 'project' and 'assigned_to' already documented in the input schema. The description's 'Filter by project' adds little beyond the schema, and it does not clarify the semantics of 'status__is_closed' or how multiple filters combine. The existing schema descriptions prevent a lower score.
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 'List epics. Filter by project.' uses a specific verb ('List') and a clear resource ('epics'), which distinguishes it from epic create/update/get tools. It does not explicitly differentiate from related list-like tools such as taiga_epics_filters_data or taiga_epics_related_userstories_list, so it stops short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It simply states the action and a filter, with no mention of when to prefer list over get, no exclusions, and no alternative tool references.
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 alone must convey behavioral traits. It only says 'update' and 'partial', but omits important context such as version conflict checking, permissions required, whether changes are reversible, or any side effects. The schema mentions the version parameter but the description does not reinforce that.
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 and immediately states the core action. While it is very brief, it is appropriately front-loaded and could easily accommodate 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?
Given the lack of annotations and output schema, plus the sparse schema coverage, the description is too incomplete. It doesn't describe the return value, prerequisites, or how partial updates behave in practice. An agent might be unsure whether it can update specific fields or how the version conflict works.
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 low at 29%, with only id and version having descriptions. The description does not explain the other five parameters (tags, color, subject, assigned_to, description) nor does it meaningfully compensate for the gap. The 'partial' hint implies that only provided fields change, but that's minimally helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Update' and the resource 'an epic', and the qualifier 'partial' specifies that only provided fields are modified. This distinguishes it from sibling tools like create, get, and delete for epics.
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 word 'partial' hints at usage, but it does not mention when not to use it or point to related tools like taiga_epics_create for new epics.
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, the description carries the full burden and merely restates that a custom attribute definition is created. It does not disclose required permissions, whether duplicate names are allowed, or how existing issue records are affected.
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, focused sentence that immediately communicates the core purpose. It is efficient, though extremely sparse, which is more a completeness concern than a conciseness flaw.
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 five parameters, no annotations, and no output schema, the description is incomplete. It leaves out response shape, required permissions, uniqueness implications, and the relationship to custom attribute values endpoints.
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 description adds no parameter-level meaning. The schema covers name, type, and project, but the 'order' and 'description' parameters remain unexplained, and the description does not compensate for the 60% schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a create action for a custom attribute definition scoped to issues. This distinguishes it from sibling tools like taiga_task_custom_attributes_create or taiga_epic_custom_attributes_create.
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 the analogous create tools for epics, user stories, or tasks. There are also no notes about prerequisites such as existing project context or uniqueness constraints.
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, the description must disclose behavioral traits but only says 'update'. It does not explain that the version parameter is used for optimistic concurrency, whether the update is partial or full replacement, what happens to unspecified attribute values, or what the response contains. 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?
The description is a single concise sentence that accurately and directly states the tool's purpose. Every word earns its place, and it is properly front-loaded with the verb and object.
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 three required parameters, including a nested object and a version for conflict checking, yet no output schema or annotations. The description omits essential usage context such as the need to obtain the current version first, whether the update is incremental or wholesale, and what the response looks like. For an update operation, 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%, with each parameter having a meaningful description ('issue ID', 'Current version for conflict check', 'Map of attribute_id -> value'). The description adds no extra semantic value, but since the schema already carries the burden, a 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 'Update custom attribute values for a specific issue' uses a specific verb and resource, clearly distinguishing this update-values tool from the corresponding get-values tool and from tools that update attribute definitions. It could further differentiate from sibling tools like taiga_issue_custom_attributes_update, but the phrase 'custom attribute values' provides enough clarity.
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. It does not mention the need to fetch the issue first to obtain the current version, nor does it contrast with the get-values or definition-update tools. The description only states the action without any 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?
With no annotations provided, the description must carry the burden of behavior disclosure, but it only states 'List issues with optional filters.' It does not mention that the operation is read-only, whether pagination or ordering is applied, any permission requirements, or potential side effects. The behavior is mostly implicit for a list operation, but critical details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundancy or filler. It is front-loaded with the core purpose. However, its terseness leaves out essential information, though that is a completeness issue, not a conciseness flaw. It earns a high score for being appropriately sized and efficient.
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?
The tool has 20 parameters, no required parameters, no output schema, and no annotations. The description offers only 'List issues with optional filters,' which is completely inadequate for an agent to understand filtering semantics, return format, pagination, or how parameters interact. This is a severe completeness gap.
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%, with 4 of 20 parameters having descriptions (tags, type, project, order_by). The description adds no parameter-specific meaning beyond 'optional filters,' leaving the other 16 parameters undocumented. It does not compensate for the low schema coverage or explain parameter relationships.
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 'List issues with optional filters' clearly identifies the action (list) and the resource (issues). It distinguishes itself from sibling list tools like taiga_tasks_list and taiga_userstories_list by explicitly targeting issues. The mention of optional filters hints at the flexible query capability.
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 explicit guidance on when to use this tool versus other list tools or how to combine filters. The description only says 'optional filters' without explaining scenarios, required parameters, or exclusions. Users must infer from the name that this is for issues, but no contextual guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source of behavioral information. It only states the action without disclosing consequences, constraints (e.g., whether statuses in use can be deleted), or permissions. This is insufficient for a mutating operation.
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 wasteful words, earning high marks for conciseness. However, the grammatical error ('a issue statuses') slightly reduces 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 simple single-ID delete tool, the description is minimal but could still benefit from stating that it deletes a specific issue status by ID and any side effects. The lack of annotations and output schema increases the need for descriptive context, which 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?
The schema already documents the single `id` parameter as required with type number and description 'ID.' The description adds no extra meaning beyond the schema, so baseline 3 applies due to 100% 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 uses the verb 'Delete' and identifies the resource 'issue statuses,' clearly indicating the tool deletes issue status objects. It specifies the scope ('issue') which distinguishes it from sibling status delete tools for user stories and tasks, though the grammar is awkward.
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 context or alternatives are mentioned. The description does not explain when to use this tool versus other status-related deletes, nor does it mention any prerequisites or effects. This leaves the agent without guidance on selection.
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 burden of behavioral disclosure. It only states 'Get', which implies a read operation, but does not mention the response format, error handling, or that it returns a single status object. The description is minimal and lacks detail beyond the basic operation.
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, front-loaded sentence that is appropriately concise. However, the grammatical error 'a issue statuses' slightly harms clarity and professionalism, preventing a perfect score.
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 tool's low complexity (one required parameter, no output schema), the description provides the minimum viable context: what it does and on what entity. It does not explain what an issue status is or what the return value looks like, but for a simple CRUD get operation, this is adequate yet not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the single parameter 'id' with 'ID', achieving 100% coverage. The tool description repeats 'by ID' without adding further semantics about the ID's format, scope, or relationship to issue statuses. Since schema coverage is high, the baseline of 3 applies, and the description does not significantly enhance parameter understanding.
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 identifies the action ('Get') and the resource ('issue statuses') with a retrieval criterion ('by ID'). While grammatically awkward ('a issue statuses'), it conveys the core purpose. It does not explicitly differentiate from sibling tools like taiga_issue_statuses_list, but the name and 'by ID' imply a single-record fetch.
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 explicit guidance on when to use this tool versus alternatives such as taiga_issue_statuses_list or taiga_issue_statuses_get_by_ref. Usage is only implied by the verb 'Get', and there are no prerequisites, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of disclosing behavioral traits. It only says 'Delete,' which implies destruction, but it does not mention that deletion is permanent, whether associated data is affected, or any auth requirements. This is a significant gap for a destructive operation.
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 concise at one sentence and front-loaded with the action. However, the grammatical error and lack of additional detail make it slightly less polished than ideal, earning a 4 rather than 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 simple delete tool, the description should at least mention that the action is irreversible and require an ID. It does neither. With no output schema and no annotations, the description leaves out critical context about the operation's effects, making it 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?
The input schema includes one parameter 'id' with a description 'ID', giving 100% coverage. Per the baseline for high schema coverage, the description doesn't need to add much, and it doesn't. It doesn't explain the format or meaning beyond ID, but the schema already provides basic info, so 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 states a clear action on a specific resource: 'Delete a issue types.' It distinguishes from sibling tools by focusing on the issue types resource. However, the grammar is awkward ('a issue types') and it doesn't explicitly mention deletion by ID, so it's not perfectly polished.
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, or any prerequisites like permissions or irreversibility warnings. The description only states the basic operation, leaving the agent to infer context from the tool 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get' without detailing side effects, authentication requirements, rate limits, or error behavior. The read-only nature is implied by the verb but not explicitly disclosed.
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 and economizes on words, but it contains a grammatical mistake ('a issue types') and does not provide much value. It is not bloated, but it's also under-specified, so it receives a medium 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 simple one-parameter retrieval tool, the description is brief but not complete. It doesn't explain what the response will be, how errors are handled, or any other context necessary for an agent to use it confidently. Given the absence of annotations and output schema, more context would be helpful.
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 fully documents the 'id' parameter, and the description's 'by ID' adds no new semantic detail. With 100% schema coverage, the description provides no additional meaning beyond what the structured schema already conveys.
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 that the tool retrieves an issue type by its ID, using the verb 'Get' and the resource 'issue types.' It is not differentiated from sibling tools like list, create, update, or delete, but it is unambiguous about the operation. The grammatical error 'a issue types' slightly hurts clarity but doesn't obscure meaning.
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 over alternatives. It doesn't mention that it's for fetching a single resource, nor does it reference sibling tools or any prerequisites. The intended use is only implied by the term 'by ID.'
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 states 'Get' which implies a read-only operation, but it does not describe return format, error behavior, permissions, or side effects. This adds little beyond what the tool name already conveys.
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, front-loaded and free of unnecessary words. However, the grammatical error 'a points' slightly harms clarity, and the brevity is close to under-specification for a tool with no other context.
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 very simple tool with one parameter and no output schema. The description is minimally viable for triggering a get-by-ID operation, but it omits information about the returned point object, possible errors, and the meaning of 'points' in Taiga. Given the low complexity, it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'id' with a description 'ID', giving 100% schema coverage. The description's phrase 'by ID' matches the schema but adds no new semantic details such as ID type, source, or format, so value is only 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 a points by ID' clearly identifies the verb (Get), resource (points), and lookup method (by ID), making the primary purpose easy to understand. However, it largely restates the tool name and does not explicitly distinguish it from other getter tools, and the grammar is slightly awkward.
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 taiga_points_list or taiga_points_get_by_ref (not present but implied by naming patterns). It lacks any mention of prerequisites, typical use cases, 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?
With no annotations, the description must disclose behavioral traits, but it only states the listing action. It does not clarify read-only implications, pagination, return payload structure, or any authentication requirements, leaving significant ambiguity.
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 two short sentences, front-loading the core purpose. It is appropriately concise with no filler, though it borders on terse.
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 list tool with one optional parameter and no output schema, the description provides the basic essentials but omits context about what priorities represent, ordering, or any response details. This is adequate for a straightforward endpoint but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'project' parameter already described as 'Project ID'. The description's 'Filter by project' adds no extra meaning beyond the schema, so the baseline of 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 clearly states the tool's action ('List priorities') and resource ('priorities'), with an optional filter by project. This distinguishes it from read-one tools like taiga_priorities_get, though it does not explicitly contrast with other list 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 such as taiga_priorities_get or other list endpoints. The mention of 'Filter by project' is a parameter detail rather than usage 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 must carry the behavioral disclosure burden. It mentions 'returns export data or starts async export', which hints at asynchronous behavior, but gives no details on authentication needs, whether the operation is read-only, or how to handle the async response. This is a significant gap for a tool with no annotations.
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, front-loaded with the main action. It is concise and free of filler, though the parenthetical could be more precise. It earns a high score for efficiency but not top because it sacrifices useful 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?
Given the simple schema and lack of output schema, the description leaves important context unstated: the distinction between sync and async modes, what the returned data looks like, and any follow-up needed for async exports. The tool's behavior is ambiguous and the description doesn't compensate for missing structured output information.
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% since the only parameter 'id' is fully described as 'Project ID'. The description adds no extra meaning beyond the schema, which aligns with baseline 3 for high 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 states the tool's verb+resource: 'Export a project', which is specific and distinct from sibling tools like taiga_projects_get. The parenthetical adds useful nuance about two possible behaviors (return data or start async), though it's slightly ambiguous. It does not explicitly contrast with taiga_projects_get but the term 'export' conveys a different 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?
There is no guidance on when to use this tool versus alternatives. It does not mention that this is for downloading a project dump or that taiga_projects_get should be used for just fetching project details. No exclusions or alternatives 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 full burden. It only states that it imports from a JSON dump but doesn't disclose whether it overwrites existing data, creates a new project, or what the side effects are. For a mutating operation, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It front-loads the verb and resource 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?
This is a mutating import tool with no annotations and no output schema. The description doesn't explain the expected outcome, whether it creates a new project, or how to obtain the dump. It leaves important operational details unstated.
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 describes the single 'dump' parameter as 'JSON string of the project export data'. The description's 'JSON dump' adds no additional detail beyond the schema. With 100% schema coverage, 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 uses the specific verb 'Import' with the resource 'project' and specifies the source 'JSON dump', clearly distinguishing it from other project operations like create or list. However, it doesn't explicitly state whether this creates a new project or overwrites an existing one, so it loses the top score.
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 such as taiga_projects_create or taiga_project_export. The description merely states the action with no context on 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?
With no annotations, the description must carry full behavioral disclosure. It only says 'Create a tag' implying a write operation, but does not mention required permissions, potential errors (e.g., duplicate tag), whether the tag is created immediately, or what the response contains. This is insufficient for an unannotated mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the core purpose without unnecessary words. It is front-loaded and easy to parse. However, it is under-specified, but that is more a completeness issue than a conciseness issue.
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 create operation with no annotations and no output schema, the description is too minimal. It fails to mention return value, side effects, or any constraints (e.g., tag name uniqueness). Given the tool's simplicity, a more complete description would include expected behavior on success or failure.
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% (all three parameters have descriptions), so the baseline is 3. The description adds no extra meaning beyond the schema; it does not clarify relationships between parameters or provide format examples. The schema already explains id, tag, and color, so the description's lack of parameter detail is neutral.
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 tag in a project' clearly states the action (create) and the resource (a tag in a project). It is specific enough to distinguish this from sibling tools like taiga_projects_edit_tag and taiga_projects_delete_tag, though it does not explicitly contrast with them.
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, nor does it mention prerequisites, uniqueness constraints, or any conditions. It simply states the action, leaving the agent without contextual cues for selection.
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, the description carries the full burden of disclosing behavioral traits. It only says 'edit,' which implies mutation, but provides no details on permissions, side effects, what happens if the tag does not exist, or whether the change is reversible. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 is front-loaded with the verb and resource, making it easy to scan. However, it is somewhat under-specified, missing details that could improve clarity 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 and no output schema, yet the description does not explain return values, required permissions, or the impact of editing a tag. The schema documents parameters but the description fails to add context about preconditions or effects, leaving the tool incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters with descriptions, so the schema already provides meaning for id, from_tag, color, and to_tag. The description itself adds no parameter semantics beyond the schema, 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 clearly states the action ('Edit') and the resource ('a tag in a project'), distinguishing it from sibling tools like create_tag and delete_tag. However, it does not specify what aspects of a tag can be edited (e.g., name, color), which would make the purpose 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?
No guidance is provided on when to use this tool versus alternatives. It does not mention that it is used for renaming a tag or changing its color, nor does it reference create_tag or delete_tag as alternatives for different 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Get project member stats.' While 'Get' implies a read operation, the description does not disclose what the stats include, whether authentication is required, or any response shape, leaving significant behavioral uncertainty.
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 concise and front-loaded with the action and resource, containing no filler or repetition. However, it is so terse that it barely adds information beyond the tool name, making it efficient but minimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description offers little to help an agent understand what 'member stats' actually returns or how it differs from related stats endpoints. The tool is simple (one parameter), but the ambiguity around the result content and sibling differentiation makes this 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?
The input schema has one required parameter, 'id', which is fully described as 'Project ID' (100% coverage). The description adds no additional parameter semantics, but since the schema already provides complete parameter information, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('project member stats'), which is specific enough to convey the tool's purpose. However, it does not explicitly distinguish itself from similarly named sibling tools like taiga_projects_stats or taiga_projects_issues_stats, so it lacks 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?
There is no guidance on when to use this tool versus alternatives, no mention of exclusions, and no context beyond the bare description. The name implies usage for member stats, but the description itself provides no explicit or implicit usage 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?
With no annotations provided, the description must fully disclose behavioral traits. It only implies a read operation ('Get') but does not describe what data is returned, whether the stats are computed on the fly, or any access requirements. This is insufficient for an agent to predict tool 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 a single concise sentence with no wasted words. While it lacks detail, conciseness itself is well-served; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (one parameter) and lack of output schema/annotations, the description still feels incomplete. It does not specify what 'stats' includes, and the existence of sibling stats tools (member stats, issues stats) creates ambiguity that the description fails to resolve.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter ('id' as 'Project ID'), so a baseline of 3 is appropriate. The description adds no additional meaning or context about the parameter beyond what the schema already 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 project stats' clearly states a verb and resource, indicating a read operation for project statistics. However, it does not distinguish this from sibling tools like taiga_projects_member_stats or taiga_projects_issues_stats, which offer more specific stats.
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 taiga_projects_list, taiga_projects_get, or other stats endpoints. The description provides no context, prerequisites, or exclusions, leaving the agent with no decision support.
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, the description carries the full burden of behavioral disclosure. It fails to mention that watching is a subscription action, whether repeated calls toggle the state, what authentication is needed, or what response is returned. This is a significant lack of transparency for a state-changing 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 extremely concise—one short sentence with no wasted words. However, while brevity is positive, it under-specifies the tool's behavior and context, making it less effective than a slightly longer description would be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description provides almost no contextual completeness. It doesn't explain what 'watching' entails, how notify_level influences behavior, the effect of calling it multiple times, or how it relates to the unwatch and watchers siblings. This leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with inline descriptions (e.g., notify_level '1=all, 2=involved, 3=none'), achieving 100% schema coverage. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Watch a project' uses a specific verb and resource, making the primary action clear. However, it doesn't differentiate from sibling tools like taiga_projects_unwatch or taiga_projects_watchers beyond the verb itself, and the meaning of 'watch' is not elaborated.
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, prerequisites, or alternatives. The description simply restates the tool's name without indicating scenarios, required permissions, or how it differs from unwatch or watcher listing 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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only says what the tool does, not whether it is read-only, how errors are handled, what type of ID is returned, or whether the lookup fails if the ref doesn't exist. This is minimal disclosure for a lookup operation.
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 redundancy. It is front-loaded with the key action, though it could be slightly more descriptive without losing 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?
The tool is simple with only two parameters and no output schema, so a short description is workable. However, it does not explain what the returned ID looks like, any failure behavior, or how 'ref' differs from 'ID', leaving moderate gaps for an agent.
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%: 'epic' is described as 'Epic ref number' and 'project' as 'Project slug'. The description adds no additional meaning beyond the schema, so the baseline 3 for high coverage 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 uses a specific verb ('Resolve') and resource ('epic ref') and states the output ('its ID'), making the core purpose clear. However, it doesn't explicitly differentiate this from sibling tools like taiga_epics_get_by_ref, which could also involve epic refs.
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 taiga_epics_get_by_ref or other resolver tools. The description is a single sentence with no context, 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 present, so the description carries full responsibility for behavioral disclosure. It only states the action without mentioning side effects (though likely read-only), error behavior, return format (e.g., whether the ID is an integer or string), or whether the task must exist. The description does not clarify if this is a pure lookup or if it performs any additional operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the action. It contains no unnecessary words. While 'Resolve a task ref to its ID' is terse, it is appropriately compact for a tool with only two parameters.
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 resolver tool with no output schema, the description does not explain what the return value looks like (e.g., just the ID, or an object containing the ID). It also does not clarify how this differs from taiga_tasks_get_by_ref or when to use this route. The minimal context leaves the agent uncertain about the output and the tool's role in a workflow.
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 for parameters is 100%, with 'task' described as 'Task ref number' and 'project' as 'Project slug'. The description adds no additional semantic meaning beyond translating 'task' to 'task ref' and 'project' to 'project slug', which is already in the schema. It does not clarify the relationship between the two parameters or provide format details, so it meets the baseline but adds little 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 'Resolve a task ref to its ID' clearly identifies the tool's function: converting a task reference number into an internal ID. The verb 'resolve' and the specific transformation (ref to ID) are precise. However, it does not distinguish between this and the sibling tool taiga_tasks_get_by_ref, which also returns task data for a ref, making the unique value less 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 usage guidance is provided. The description does not state when to use this resolver versus taiga_tasks_get_by_ref or other sibling resolvers like taiga_resolver_userstory. It lacks any mention of use cases, prerequisites, or conditions under which this tool should be preferred.
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 transparency burden. It does not disclose whether listing is global or per-project, any ordering or pagination behavior, required permissions, or the return format. The phrase 'Filter by project' is the only behavioral hint and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler or repeated information. It is perfectly concise and front-loaded, with every word contributing to the basic understanding.
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 list tool with no annotations and no output schema, the description leaves key questions unanswered: does it list all roles when no project is given? What is the response structure? The description is too minimal for an agent to fully anticipate behavior.
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 fully documents the single parameter as 'Project ID', and the description's 'Filter by project' adds little beyond restating the parameter's purpose. With 100% schema coverage, the baseline is 3, and no additional meaning is provided.
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 tool lists roles and mentions filtering by project, making the action and resource unambiguous. It does not explicitly distinguish from sibling list tools, but the resource 'roles' is unique among the available 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 vs alternatives such as taiga_roles_get or taiga_roles_create. The optional project filter is mentioned but not contextualized, and no exclusions or alternative scenarios are described.
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 only says 'bulk update order,' implying a write operation, but does not explain whether the provided pairs replace the entire order, how unlisted severities are affected, or any project-level constraints. This is minimal and leaves significant ambiguity.
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, front-loaded sentence with no unnecessary words. It efficiently communicates the core purpose. However, it is under-specified, which prevents a perfect score of 5.
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 relatively simple with two fully described parameters and no output schema, so the description provides a minimal viable summary. However, it lacks behavioral context (e.g., order semantics, effect on unlisted severities, authentication expectations) that would be valuable for a bulk mutation tool with no annotations. It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters clearly ('Project ID' and 'Array of [id, order] pairs'), so schema coverage is 100%. The description adds no additional meaning beyond the schema, but the schema is sufficient. The baseline of 3 applies because the description does not compensate or add further context.
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 specific action ('bulk update') and resource ('order of severities'), clearly indicating it reorders severities. It does not explicitly differentiate from sibling bulk_update_order tools, but the resource name is unambiguous. It is more informative than a mere tautology but lacks the specificity of top-tier descriptions.
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, such as `taiga_severities_update` for single severity changes or other bulk order update tools. The description does not mention prerequisites, exclusions, or context. Usage is only implied by the tool name.
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 must disclose behavioral traits, but it only says 'Delete.' It does not mention permanence, cascading effects, permissions, or reversibility, leaving the agent without crucial safety information.
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 concise at one sentence, but it adds little beyond the tool name and is too sparse to be informative. It lacks the substance expected to justify its presence.
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 delete-by-id tool, the description is minimal and omits any context about consequences or usage. The absence of annotations and output schema places more burden on the description, which it does not meet.
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 fully describes the single 'id' parameter, so the description adds no additional semantics. Since schema coverage is 100%, the baseline score is 3, but the description does not compensate with any extra detail.
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 specific verb ('Delete') and resource ('severities'), making the operation clear. However, it is essentially a restatement of the tool name and contains a grammatical error ('a severities'), so it does not add meaningful differentiation from sibling 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, what prerequisites or permissions are required, or how it differs from other severity operations (e.g., taiga_severities_update). The description offers no context for appropriate invocation.
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 only states the action without mentioning required permissions, side effects on existing tasks, duplicate handling, or the response shape. The agent has no information about what happens after creation.
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 filler. It is front-loaded and easy to parse, though it could benefit from a bit more structural detail about parameters or usage.
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 simple create operation, but the lack of annotations, output schema, and usage guidance leaves the agent without critical context such as permissions, return values, and how this relates to custom attribute values. The one-line description is not complete enough for reliable 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?
The description adds no parameter-level meaning. The schema provides descriptions for 'name', 'type', and 'project' (60% coverage), but parameters 'order' and 'description' are undocumented in both the schema and the description. The tool description does not compensate for this gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' and clearly identifies the resource as a 'custom attribute definition for task'. It distinguishes this tool from sibling operations like update/delete/list on task custom attributes and similar create tools for epics, user stories, and issues.
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 does not state when to use this tool versus related endpoints, does not mention prerequisites such as project membership or permissions, and does not clarify that custom attribute values are managed through separate value endpoints.
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 only says 'update' with no mention of required permissions, whether the update is partial or full, side effects, or error behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clearly worded sentence with no unnecessary words. It is front-loaded with the verb and resource, making it easy to parse quickly.
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 description is too terse for a tool with 5 parameters, no annotations, and no output schema. It omits essential information such as which fields are updatable, whether it's a partial update, and any prerequisites or side effects. An agent would need to rely on the sibling tools or external documentation to use it 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?
The input schema covers only 20% of parameters with descriptions (only id). The description does not list or explain any of the updatable fields (name, type, order, description), leaving the agent to infer their meaning from the parameter names alone. This does not compensate for the schema's low 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 clearly states the action (update) and the resource (custom attribute definition for task). The word 'definition' distinguishes it from the sibling tool that updates attribute values (taiga_task_custom_attributes_values_update). It also specifies 'task' to differentiate from epic/userstory custom attribute updates.
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 over alternatives. It does not mention that it modifies the definition as opposed to values, nor does it reference any sibling tools for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only says 'Get', implying a read operation, but reveals nothing about response structure, permission requirements, side effects, or any caveats—leaving the agent without essential context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single eight-word sentence, front-loaded with the action and resource, with zero wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one well-documented parameter, but no output schema exists and the description does not clarify what 'filters data' returns or why a user would need it. This makes it minimally viable for selection and invocation, yet it leaves a clear gap for an agent that lacks domain-specific Taiga knowledge.
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 fully documents the sole 'project' parameter with 100% coverage, so the baseline is 3. The description's phrase 'in a project' reinforces the parameter's purpose but adds no new format or syntactic detail beyond what the schema already 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 uses a specific verb 'Get' and scopes the resource to 'tasks in a project', distinguishing it from sibling filters_data tools for epics, user stories, and issues. It does not explain what 'filters data' contains, so it stops short of a perfect score.
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 taiga_tasks_list, taiga_search, or other filter-related endpoints. The description simply restates the action without exclusions or alternative suggestions.
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 disclose behavioral traits. It only mentions 'partial', which hints at partial-update semantics, but it does not disclose version-conflict behavior, permission requirements, side effects, or response format. This is minimal 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?
The description is concise, one sentence with no wasted words. It lacks structured sections, but for a simple CRUD operation, that is acceptable. It is shorter than ideal but every word earns its place.
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 13 parameters, 2 required, no output schema, and no annotations. The description is extremely minimal, offering no elaboration on the meaning of the many optional fields, the version-conflict mechanism, or expected outcomes. This is insufficient for an agent to correctly invoke the tool with confidence.
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 15%, covering just id and version. The description does not list or explain any of the other 11 parameters. The word 'partial' implies that only provided fields are updated, which is a small semantic contribution, but it does not compensate for the lack of descriptions for fields like status, milestone, assigned_to, etc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a task (partial).' clearly identifies the action (update) and resource (task). The word 'partial' adds useful detail about the operation's nature, distinguishing it from create/delete. However, it does not explicitly distinguish itself from other update tools for different resources, though the tool name itself makes this clear.
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 provides no explicit guidance on when to use this tool versus alternatives. However, the name 'taiga_tasks_update' and the sibling list imply that it is used to modify an existing task, in contrast to create or delete. This is implied usage rather than 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states the action without explaining idempotency, authentication requirements, side effects (e.g., incrementing a vote count), or error conditions. There is also no mention of whether the upvote can be removed or what happens if the user already upvoted.
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, short sentence 'Upvote a task.' It is concise, front-loaded with the action and resource, and contains no unnecessary words. For a simple tool with one parameter, this level of brevity is appropriate and well-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 the tool's simplicity, a short description might suffice, but it lacks essential context: no return value, no effect description, no prerequisites, and no connection to sibling tools. Since there is no output schema, the description should at least indicate what the response contains or any postconditions. The description is too minimal to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single parameter 'id' as 'Task ID', so the description adds no extra meaning beyond what the schema provides. With 100% schema description coverage, the baseline is 3, and the description does not enhance parameter understanding further.
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 'Upvote a task' clearly states the action (upvote) and the resource (task), making it specific. However, it does not explicitly distinguish itself from sibling upvote tools for other entities like epics or user stories, though the resource is clear from the name. It is a clear, minimal purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, no mention of prerequisites, and no alternatives or exclusions. It does not explain how upvoting relates to watching, liking, or downvoting, offering no helpful context for tool selection among 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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action. It does not mention pagination, authentication requirements, or what the timeline response contains, leaving significant ambiguity.
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, front-loaded with the core purpose. It is efficient, though under-specified, so it loses a point for not using the space to add more 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 tool with no output schema and no annotations, the description is too thin. An agent cannot infer what a 'timeline' contains, how pagination works, or how this tool relates to the timeline_user/profile variants. The page parameter is unexplained, leaving the usage incomplete.
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 50%: project_id has a minimal description and page has none. The description adds no meaning for page, which is likely a pagination parameter, and does not clarify how project_id should be formatted beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'timeline for a project', which distinguishes it from sibling tools like taiga_timeline_user and taiga_timeline_profile. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as taiga_timeline_user or taiga_timeline_profile. No context, exclusions, or conditions 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?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action without explaining side effects (e.g., how existing sprint order is modified), permissions, or response behavior. This is a significant gap for a bulk mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words, front-loading the core action. It is appropriately terse for the tool's simplicity, though slightly under-specified in content.
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 simple (2 params, no output schema), but the description is minimal. It omits critical context such as what sprint order means, whether the pairs must be in order, or how partial failures are handled. Given no annotations, this is inadequate.
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 the baseline is 3. The description adds no meaning beyond the schema; 'bulk_stories' already describes 'Array of [us_id, order] pairs' in the schema, and the description does not enrich this with examples or constraints.
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 action: bulk updating sprint order of user stories. It uses a specific verb ('bulk update') and resource ('sprint order of user stories'), and the singular 'sprint order' hints at distinguishing from backlog/kanban order siblings, though it doesn't explicitly differentiate.
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 like bulk_update_backlog_order or bulk_update_kanban_order. The description provides no context, prerequisites, or exclusions, so the agent receives no decision support.
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 mention that deletion is likely irreversible, that the user story must exist, or any side effects. This is a significant gap for a destructive operation.
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 fluff. It is front-loaded and clear. However, it is under-specified in terms of warnings, but that is a completeness issue rather than 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?
For a simple one-parameter delete tool, the description might seem adequate, but with no annotations or output schema, it should warn about permanence or permissions. It lacks this essential context, making it incomplete for a destructive action.
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 fully describes the 'id' parameter as 'User Story ID' (100% coverage), so the baseline is 3. The description does not add any extra meaning beyond the schema, so no additional credit is warranted.
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 action clearly: 'Delete a user story.' This is a specific verb and resource, and it distinguishes from sibling user story tools by the delete operation. However, it lacks any additional context about scope (e.g., permanent vs reversible), so it doesn't fully differentiate beyond the verb.
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 simply states the action without any context, exclusions, or mention of prerequisites. The agent must rely entirely on the tool name to infer usage.
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 bears full responsibility for behavioral disclosure, but it only says 'Get filters data.' It does not reveal read-only nature explicitly, return format, pagination, required permissions, or any side effects. The verb 'Get' implies read-only, but this is implicit and 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?
The description is a single, clear sentence with no filler or repetition. It is front-loaded with the action and resource. It sacrifices some helpful detail for brevity, but the structure itself is efficient and tidy.
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 one parameter, no output schema, and no annotations, but the description still fails to explain what 'filters data' includes or how the result is structured. Given similar sibling tools (e.g., epics, tasks, issues filters_data), the description offers no context on return values or expected use, leaving the agent under-informed.
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 'project' described as 'Project ID.' The description does not add any extra meaning beyond the schema, but since the schema already fully documents the only parameter, a baseline score 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 clearly states the verb ('Get'), the resource ('filters data for user stories'), and the scope ('in a project'). It distinguishes from sibling filters_data tools by explicitly naming user stories, though it does not clarify what 'filters data' means.
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 taiga_userstories_list or the epics/tasks/issues filters_data siblings. The description only states the general action and does not mention exclusions, prerequisites, or alternative use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only says 'Upvote a user story' without disclosing consequences, reversibility, required permissions, or response format. As a mutation tool, 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?
The description is one short sentence, immediately stating the action and target. There is no filler or redundancy, making it exceptionally concise 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?
Given the tool's simplicity (one param, no output schema) and lack of annotations, the description is minimally informative. It does not explain the effect of upvoting, how it relates to downvoting, or what the caller should expect in return, making it insufficient for confident selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the sole parameter 'id' as 'User Story ID' (100% coverage). The description adds no additional meaning or context about the parameter, so the baseline of 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 clearly states the action (upvote) and the resource (a user story), which distinguishes it from sibling tools like taiga_epics_upvote or taiga_tasks_upvote. However, it adds no additional scope or context beyond the tool 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?
The description provides no guidance on when to use this tool versus alternatives such as taiga_userstories_downvote, taiga_userstories_voters, or watch tools. There is no mention of prerequisites, auth, or intended scenarios.
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, the description carries the full burden of behavioral disclosure. It only says 'delete', which implies destruction, but it doesn't mention irreversibility, permission requirements, or potential failures (e.g., cannot delete a status in use). The description adds no context beyond the verb.
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, short sentence with no filler words. It is appropriately front-loaded and concise, though it is also minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, a short description could be sufficient, but this one omits essential context such as the fact that deletion is by ID, the irreversible nature, or any caveats about statuses in use. With no output schema and no annotations, the description is incomplete for an agent to understand the full implications.
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 covers the single 'id' parameter with a description ('ID'), so the baseline is 3. The tool description does not add any additional meaning or context for the parameter, leaving the schema to carry the parameter semantics.
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 userstory statuses' clearly states the action (delete) and the resource (userstory status), though the grammar is awkward. It distinguishes from sibling tools by mentioning the specific resource type and the delete verb, but it doesn't add any additional context beyond what the tool name already conveys.
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, prerequisites, or alternatives. There is no mention of when deletion is appropriate, what happens to related data, or that users should use update/bulk_update_order for reordering 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 the full burden of behavioral disclosure. It only states that the tool lists items voted by a user; it does not disclose whether this is a read-only operation beyond the verb 'List', what item types are included, pagination behavior, authentication requirements, or error conditions.
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, front-loaded with the verb and resource, containing no wasted words. It earns its place, though it is minimal and could benefit from 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?
Although the tool is simple with one parameter, the absence of an output schema and annotations means the description should clarify what 'items' refers to or what the caller can expect in the response. The description remains too vague to fully support confident invocation.
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 the single parameter 'id' already described as 'User ID'. The description 'List items voted by a user' adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'List' and resource 'items voted by a user', making the primary purpose clear. It distinguishes from siblings like taiga_users_liked and taiga_users_watched by focusing on 'voted'. However, 'items' is vague and does not specify whether these are epics, user stories, tasks, or issues.
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. Sibling tools such as taiga_epics_voters, taiga_tasks_voters, and taiga_users_liked exist, but the description does not mention any context, exclusions, or alternative selection criteria. Usage is only implied by the name and one-line description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden of behavioral disclosure. It only states the action ('List webhook logs') without mentioning pagination, default limits, response structure, authentication requirements, or whether omitting the webhook parameter returns all logs. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences with no redundant words. 'List webhook logs' is an immediate action statement, and 'Filter by webhook' adds necessary scope in one clause.
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 no output schema and no annotations, the description is too sparse to fully guide an agent. It does not explain what the returned logs contain, whether the webhook parameter is optional (schema says optional, but description doesn't state the default behavior), or any limitations. For a simple list tool, more context is expected.
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 provides a single parameter 'webhook' described as 'Webhook ID', and the tool description adds that it serves as a filter. This adds a small semantic layer (the parameter is a filter, not a resource locator) beyond the schema, but the schema already documents the parameter fully, 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 clearly states the tool's action ('List') and resource ('webhook logs'), and the filter criterion ('Filter by webhook') adds scope. However, it does not explicitly distinguish itself from the sibling 'taiga_webhooklogs_get', relying on the implied difference between 'list' and 'get'.
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 'taiga_webhooklogs_get' or 'taiga_webhooklogs_resend'. There is no mention of typical use cases, whether the webhook filter is optional, or any conditions under which this tool should be preferred.
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 discloses the core action of 'sending a test payload,' but omits important behavioral details such as whether this triggers a real HTTP request to the webhook endpoint, potential side effects on external systems, or what happens on success/failure. This is a significant gap for a test 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 sentence with no redundant words: 'Test a webhook by sending a test payload.' It is front-loaded and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and a single parameter, the description is quite minimal. It does not explain when to use this tool, what the test payload entails, or what the agent should expect after invocation. For a tool that triggers an external webhook, this lacks essential context for an agent to use it 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 description coverage is 100%, with the parameter 'id' already documented as 'Webhook ID.' The description adds no additional meaning about the parameter, so it does not surpass the baseline. The schema provides all needed detail.
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 and resource: 'Test a webhook' with the mechanism 'by sending a test payload.' It clearly identifies the tool's action, though it does not explicitly differentiate from sibling webhook tools like taiga_webhooks_list or taiga_webhooklogs_resend. The purpose is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as taiga_webhooks_create or taiga_webhooklogs_resend. It lacks context about prerequisites (e.g., webhook must exist) or exclusions. Usage is only implied by the verb 'test.'
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 only restates the create action implied by the tool name and omits edge-case behavior such as duplicate slug handling, permission requirements, return values, and side effects like watcher notifications.
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 four-word sentence with zero redundancy and the key action fully front-loaded. It is structurally efficient, though the extreme brevity edges toward under-specification rather than maximally effective 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?
For a mutation tool with no annotations, no output schema, and four parameters, a four-word description is inadequate. It omits expected return behavior, conflict handling for duplicate slugs, and preconditions, leaving the agent without sufficient context for confident 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?
The schema covers 75% of parameters (project, slug, content), but the description adds no additional parameter context. The optional 'watchers' parameter remains unexplained in both the schema and the description.
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 states a specific verb ('Create') and resource ('a wiki page'), making the tool's intent immediately clear. It distinguishes this from siblings like taiga_wiki_update, taiga_wiki_delete, and taiga_wiki_links_create, since only this tool creates wiki pages.
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. It does not mention prerequisites, conditions for non-use, or that taiga_wiki_update handles modifications to existing pages.
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, the description carries full responsibility for behavioral disclosure, but 'Create a wiki link.' only states the basic action. It does not describe side effects, required permissions, response format, or any constraints, providing minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with zero wasted words, making it very concise and front-loaded. While it is terse, it earns its place given the tool's simplicity, though it could include a bit more context without losing 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?
For a create operation with no annotations and no output schema, this description is incomplete. It lacks context about what a wiki link is, the relationship to wiki pages, or any usage details. The schema covers parameters well, but the overall tool context 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 coverage is high (75%: project, title, href have descriptions), so the baseline is 3. The description adds no parameter details beyond the schema, but the schema itself already documents most parameter meanings.
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 wiki link.' has a specific verb and resource, clearly distinguishing it from sibling tools like taiga_wiki_create (create wiki page) and wiki link list/get/update/delete. However, it does not elaborate on what a wiki link is or its purpose, so it's clear 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention situations where creating a wiki link is appropriate, nor does it reference sibling tools or prerequisites.
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. It does not mention idempotency, whether the user must already be watching, error cases, or return behavior. The description adds no value beyond what the tool name already implies.
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 no wasted words. It is front-loaded and appropriately sized for the tool's simplicity, earning a top score for 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?
Given no annotations and no output schema, the description is incomplete for a state-changing operation. It fails to disclose idempotency, prerequisites, or the effect of unwatching, which are important for an agent to invoke it correctly. The minified description leaves too much implicit.
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 covers 100% of the parameter descriptions ('id' with 'Epic ID'), so the description adds no additional meaning. According to the rubric, a high schema coverage baseline of 3 applies.
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 'Stop watching an epic.' clearly states the action (unwatch) and the resource (an epic), using a specific verb and noun. It distinguishes from sibling tools like watch, watchers, and unwatch for other resources.
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, no contextual prerequisites, and no exclusions. The description only states the action without any scenario or comparison, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no additional behavioral context, the description merely restates the action 'Delete' without disclosing whether deletion is permanent, reversible, or has cascading effects on associated user stories. It does not warn about potential destructive consequences, which is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single short sentence that conveys the core action without unnecessary words. It is appropriately front-loaded and contains no filler, earning a high conciseness score despite being otherwise minimal.
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 relatively simple with one parameter and no output schema, but the description omits any information about permissions, reversibility, or side effects. For a delete operation, the lack of destructive-action warnings makes the description incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter 'id' as a number representing the Milestone ID, achieving 100% coverage. The description adds no new information about the parameter, so by the baseline rule, the score is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and identifies the resource as 'a milestone/sprint', which aligns with the tool's name and distinguishes it from sibling tools for listing, creating, getting, and updating milestones. It makes the primary purpose 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?
The description provides no guidance on when to use this tool versus alternatives, such as when a milestone should be permanently removed versus updated or archived. There are no prerequisites, warnings, or references to related tools, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only states 'Create a new project' and gives no information about side effects, required permissions, response format, or idempotency. This falls short of transparent disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently states the core purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, no annotations, no output schema, and a highly incomplete schema description, this description is severely inadequate. It fails to explain the meaning of optional parameters, the return value, or any operational context, leaving the agent without crucial information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11%, with only the 'name' parameter documented. The description adds no meaning for the other eight parameters (e.g., is_private, description, total_milestones) and does not compensate for the low coverage. It leaves the agent without understanding of optional fields.
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 'Create a new project.' clearly states the action (create) and the resource (project), which distinguishes it from sibling tools like taiga_projects_update, taiga_projects_delete, and taiga_projects_list. The verb-resource pairing is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a new project needs to be created, but it provides no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It is not misleading, but the context is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only states 'Bulk create user stories,' which merely restates the function name and reveals nothing about return values, side effects, error handling, or required context. 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 extremely concise, consisting of a single sentence with no wasted words, and the key action is front-loaded. However, it is so brief that it borders on under-specification, though for sheer efficiency it works well.
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 3 parameters, 2 required, and no output schema or annotations, so a concise but informative description is essential. This description fails to mention the role of status_id, what the tool returns, or how batch creation behaves on partial failure, making it incomplete.
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 already documents project_id and bulk_stories (67% coverage), but the description adds no parameter information. It does not explain the optional status_id parameter, which is undocumented in both the schema and description, nor does it clarify the expected format of bulk_stories beyond what the schema already says.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb phrase 'Bulk create' and identifies the resource as 'user stories', clearly conveying that this tool creates multiple user stories at once. This distinguishes it from the single-userstory creation tool (taiga_userstories_create) and other bulk operations.
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 provides no explicit guidance on when to choose this tool over alternatives such as taiga_userstories_create. The word 'bulk' implies it is for batch creation, but there is no stated criterion for when to use it, no prerequisites, and no mention of what differentiates it from other bulk create 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it updates a definition, without mentioning side effects, permissions, idempotency, or behavior when the id does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It is appropriately sized for a simple update operation, even if it lacks 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 mutation tool with five parameters and no output schema, the description is insufficiently complete. It does not outline which fields can be updated, what the response will be, or any required context such as the need for an existing custom attribute.
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 low (20%), and the description does not compensate by explaining the meaning or usage of the 'name', 'type', 'order', or 'description' parameters. Only the 'id' is documented in the schema, leaving most parameters under-described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') with a specific resource ('custom attribute definition') and scope ('for epic'), clearly distinguishing it from sibling tools like taiga_epic_custom_attributes_list/get/delete and from the values_update variant.
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. It does not mention that it updates the attribute definition (metadata) rather than values, nor any context such as prerequisites or typical use cases.
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, the description carries the burden of behavioral disclosure. 'Create a new epic' implies a write operation but does not mention permissions, side effects, response format, or reversibility. It is slightly above a score of 1 because it at least clearly conveys the mutating 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?
The description is a single concise sentence with no filler or redundancy. It is appropriately front-loaded, stating the exact action immediately. While terse, under-specification is penalized in other dimensions, not 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 create operation with 7 parameters, no annotations, and no output schema, this one-line description is severely under-specified. It does not explain required fields, expected behavior, or what the caller will receive. It is barely above the 'Process' tautology level.
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 43%, so the description must compensate for undocumented parameters. It does not mention any parameters, leaving tags, watchers, assigned_to, and description unexplained. The schema's own descriptions for project, subject, and color are the only help, but the description adds zero value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new epic' is a specific verb+resource statement. It clearly distinguishes this tool from sibling tools like taiga_epics_bulk_create (singular 'a new epic') and from create tools for other entities (userstories, tasks, etc.).
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, no prerequisites, and no exclusions. It simply states the action without context such as 'use this for single epic creation; for bulk creation use taiga_epics_bulk_create'.
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, the description carries the full burden of behavioral disclosure. It implies a read-only operation via 'Get' but does not describe the response structure, required permissions, or the nature of the returned filter data. The description adds minimal behavioral detail beyond what the tool name already conveys.
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 no redundancy or filler. It is front-loaded with the verb and resource, making it easy to parse and directly informative.
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 one-parameter, read-only tool with no output schema, the description is minimally sufficient but leaves gaps. The term 'filters data' is vague, and the description does not specify what the response contains or any prerequisites, making it incomplete for an agent needing full understanding of expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the only parameter 'project' with a clear description ('Project ID') at 100% coverage, so the schema already provides the necessary semantic information. The description adds no further parameter-level detail, aligning with the baseline score of 3.
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 ('Get') and resource ('filters data for epics in a project'), distinguishing it from sibling tools like taiga_epics_list and other filters_data endpoints. However, it does not explain what 'filters data' consists of, leaving some ambiguity about the exact output.
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 such as taiga_epics_list or taiga_userstories_filters_data. It simply restates the tool's function, requiring the agent to infer usage context without explicit 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?
With no annotations provided, the description must carry the burden of disclosing behavior. It only says 'bulk add', which implies mutation, but does not reveal that new user stories are likely created (based on 'subjects'), whether the operation is atomic, or what happens on partial failure. No side effects are disclosed.
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 no filler. It is easy to parse and front-loaded with the action.
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 3-parameter tool with full schema coverage and no output schema, the description is minimally adequate. However, it lacks context about the creation behavior and the effect on the epic, which is important for an agent deciding whether to invoke this tool. It does not explain the return value or any prerequisites.
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 all parameters well. The description adds the concept of 'bulk' and 'epic' but does not add meaning beyond what is already in the parameter descriptions. 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?
'Bulk add user stories to an epic' clearly identifies the action (bulk add) and resource (user stories to an epic). It distinguishes from the singular 'related_userstories_add' sibling, but does not clarify whether the user stories already exist or are being created, leaving some ambiguity.
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 the singular add tool. It does not state that it is for creating new user stories in bulk or that it should be preferred over individual adds. No context or exclusions 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?
With no annotations, the description is the only source of behavioral information. It merely states the action without disclosing side effects, idempotency, authentication requirements, or behavior on repeated upvotes.
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 short, front-loaded sentence with no wasted words. It is direct and easily parsed, though it may be under-specified for an 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?
The description omits usage context, differentiation from related voting operations, and outcome details. For a simple action, it still leaves important behavioral questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'id' parameter as 'Epic ID' (100% coverage). The description adds no additional parameter meaning, but the schema sufficiently explains it, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Upvote' and identifies the resource as 'an epic', which clearly distinguishes it from sibling tools like taiga_epics_downvote. It unambiguously states the action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as downvote or voters. There is no context about appropriate scenarios, 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 present, so the description carries the full burden. It states the write action but does not mention required permissions, success/failure behavior, partial creation semantics, or response format.
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 highly concise and front-loaded, with no filler. However, it is so sparse that it borders on under-specification, though for a two-parameter tool a short sentence can be acceptable.
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?
Without annotations or output schema, the description leaves out important context such as return values, prerequisites, and any side effects. It is functional but incomplete for an agent selecting this tool among many siblings.
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%; the schema already describes project_id and bulk_issues as 'Newline-separated issue subjects'. The description adds no parameter-level detail beyond the schema.
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 'Bulk create issues' clearly identifies the operation: creating multiple issues at once. It distinguishes from sibling taiga_issues_create by the 'bulk' qualifier and from other bulk-create tools by naming issues as the target.
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 choose this over taiga_issues_create or how bulk creation should be used. The only implication is from the word 'bulk'.
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 implies a read-only list operation but does not state return format, pagination behavior, or what happens when the optional project filter is omitted. This leaves significant ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences, front-loaded with the core action and filter. There is no wasted wording or redundant information, making it easy to parse quickly.
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 list tool with one optional parameter and no output schema, the description is minimally adequate. It communicates the core operation and filter, but lacks details about the response shape or default behavior (listing all issue types). Given the low complexity, this is sufficient 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?
The input schema already describes 'project' as 'Project ID', and the description simply repeats the filtering concept without adding new semantic detail. Since schema coverage is 100%, the baseline of 3 applies; the description adds no value 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 clearly states the action ('List issue types') and the resource, distinguishing it from sibling tools like taiga_issues_list or taiga_issue_statuses_list. It also mentions an optional filter ('Filter by project'), adding scope. It is not a 5 because it lacks any broader context or purpose beyond the minimal definition.
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. The description only says 'Filter by project' but does not explain when a user should list issue types vs. statuses, priorities, or other related lists, nor does it mention any exclusions or alternative 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 responsibility for disclosing behavioral traits. It only states the action without revealing side effects, permission requirements, reversibility, or the exact effect on the point ordering. As a mutation tool, the absence of such context 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 sentence with no redundant words, making it concise and front-loaded. It efficiently conveys the core action, though it may be too sparse for other dimensions. For the purpose of conciseness, it earns a high 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?
Given no annotations and no output schema, the description must be self-sufficient. It fails to explain the ordering semantics, the impact on existing points, or any project-level requirements. The tool is simple, but the description is too minimal to fully guide an agent through correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds no extra meaning beyond the schema; it does not elaborate on how 'project' or 'bulk_orders' should be used. The schema's 'Array of [id, order] pairs' is self-explanatory, but the description contributes nothing additional.
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 'Bulk update order of points' clearly states a specific action (bulk update) on a specific resource (points), using a direct verb. It distinguishes from sibling tools by naming 'points' as the target, though it does not explain what points represent in Taiga beyond the name. This is clear enough for an agent familiar with the domain.
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 bulk usage via the word 'bulk', which separates it from individual point update tools like taiga_points_update. However, it gives no explicit guidance on when to choose this tool over alternatives, nor does it mention any prerequisites or exclusions. The usage context is only implied.
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 simply states 'Get project issues stats' without revealing what statistics are included (e.g., counts by status, severity), whether it is read-only, or what the response format is. The description is minimal and does not add meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 is appropriately brief for a simple one-parameter tool, though it could have used the space to include more useful details about the stats 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 tool has no output schema and no annotations, so the description must explain what the tool returns. It only states the purpose (getting project issues stats) but does not specify the content of those stats, any limitations, or the nature of the response. For a stats tool, this is a significant 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?
The input schema already provides 100% coverage with a description for the only parameter ('id' -> 'Project ID'), so the baseline is 3. The description 'Get project issues stats' adds no additional meaning beyond what the schema already states, such as how the id relates to the stats or any special formatting.
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 'Get project issues stats.' uses a clear verb ('Get') and specific resource ('project issues stats'), which distinguishes it from sibling tools like taiga_projects_stats (general project stats) and taiga_projects_member_stats (member-specific stats). It is unambiguous and directly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention explicit use cases, exclusions, or alternatives such as taiga_projects_stats or taiga_issues_list. The only implied usage comes from the tool name itself, not from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the partial-update nature, which is useful, but it does not mention side effects, permissions required, idempotency, or what happens to omitted fields. For a mutation tool, 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?
The description is a single, front-loaded sentence that gets straight to the point. Every word contributes meaning, and there is no redundancy or filler. It is concise without sacrificing the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is severely under-specified. It identifies the resource and operation but does not explain the fields, expected return value, or any behavioral constraints. An agent relying solely on this description would lack critical context for 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 13% (only 'id' has a description), and the description does not compensate. 'Partial update' implies that the fields are optional, but it does not explain the meaning or purpose of fields like is_private, is_wiki_activated, or is_backlog_activated beyond their names. The description adds minimal value over the raw schema.
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 'Update a project (partial update)' clearly states the action (update) and the resource (project), and adds the important scope qualifier 'partial update' which distinguishes it from full replacement. This clearly differentiates it from sibling project tools like taiga_projects_create, taiga_projects_get, and taiga_projects_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not specify prerequisites, mention when to prefer create/delete, or note any permissions needed. The only implied usage is 'when you need to update a project,' which is not explicit enough to guide an agent.
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, the description carries the full burden of behavioral disclosure. It merely restates the tool's name with the word 'List', implying a read-only operation but adding no details about return format, pagination, authentication, or side effects.
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 clear sentence, 'List watchers of a project.', with no redundant words and the action front-loaded. It is appropriately 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?
For a simple one-parameter read-only tool the description is minimally adequate, but it does not explicitly state what the response contains or any edge cases. Since there is no output schema, a brief note about the return payload 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?
The input schema has one parameter 'id' with a description 'Project ID', providing 100% coverage. The tool description adds no additional parameter explanation, so the baseline of 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 uses a specific verb ('List') and resource ('watchers of a project'), clearly stating what the tool does. It inherently distinguishes from sibling tools like taiga_projects_watch/unwatch and taiga_projects_fans, though it doesn't explicitly name them.
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 taiga_projects_fans or the watchers endpoints for other entities. There is no mention of context, 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 present, so the description alone must disclose behavioral traits. It only repeats the action implied by the tool name ('Create a new role') and does not mention required permissions, project scope, duplicate handling, or side effects.
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, front-loaded sentence with no wasted words. It is efficient, though extremely terse; it could include a little more context without losing 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?
For a mutation tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It lacks project-scoping information, permission requirements, and any relationship to sibling role tools, leaving the agent to rely solely on the schema.
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 80%, with descriptions for name, project, computable, and permissions. The description itself adds no parameter semantics beyond the schema, so the baseline score of 3 applies; the undocumented 'order' parameter is not clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' and the resource 'role,' clearly distinguishing this tool from sibling operations like taiga_roles_list/get/update/delete. It succinctly identifies the action and object.
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 taiga_roles_update or other role operations. The verb 'Create' implies adding a new role, but there are no prerequisites, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action, omitting critical details such as whether deletion is permanent, what happens to users assigned to the role, or required permissions. No safety or side-effect information 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?
The description is extremely concise, using only two words, with no wasted content. It is front-loaded and easily parseable, though it could be slightly more descriptive without losing 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?
The tool is a destructive operation with no annotations and no output schema. The description fails to mention permanence, permissions, or related context (e.g., what happens to memberships using the role). Given the simplicity of the tool, it is still 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?
The input schema already fully documents the single parameter 'id' with description 'Role ID' (100% coverage). The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a role.' uses a specific verb and resource, clearly distinguishing it from sibling tools like taiga_roles_list, taiga_roles_create, and taiga_roles_get. It unambiguously states the action and target.
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, nor any exclusions or prerequisites. It simply says 'Delete a role.' without context on role usage, permissions, or consequences.
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 only states that the tool lists severities and can filter by project, but it does not disclose whether this is a read-only operation, what the return format is, if pagination applies, or any authentication requirements. For a simple list tool 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 exceptionally concise: two short sentences that immediately state the action and the optional filter. It is front-loaded with the primary purpose and contains no unnecessary words or filler. Every word contributes to the meaning.
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 tool's simplicity (one optional parameter, no output schema, no annotations), the description is minimally adequate. It covers the core action and the filter, but it does not mention the return value or any behavioral notes. For an agent, this may be enough to call the tool, but it lacks the context to fully understand the output or usage boundaries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the sole parameter 'project' as 'Project ID' with 100% coverage. The description adds the phrase 'Filter by project,' which clarifies the parameter's role as an optional filter, providing some additional meaning beyond the raw schema. However, this is a minimal addition, so the score stays at the baseline of 3.
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 tool lists severities, with a specific verb and resource. It adds the filter-by-project capability, which gives scope. However, it does not explicitly distinguish this from sibling list tools (e.g., taiga_priorities_list), though the resource name itself differentiates it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for listing all severities as opposed to fetching a single severity (taiga_severities_get) or that similar list tools exist for other resources (e.g., priorities, issue types). The usage context is essentially implied by the tool name.
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 only says 'Get', implying a read operation, but does not disclose what is returned (e.g., metadata, content, URL), potential errors, or any authorization requirements. This is a minimal disclosure with no behavioral detail beyond the verb.
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 no filler or redundancy. It communicates the core purpose efficiently.
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 very simple (one parameter, no output schema), and the description is minimally viable. However, with no annotations and no output schema, the description could add context about the return value or usage context. It is adequate but lacks depth—for example, it does not clarify whether the response is binary file content or attachment metadata.
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 documents the only parameter 'id' with description 'Attachment ID', so schema coverage is 100%. The description adds no additional meaning about the parameter, such as how to obtain the ID or whether it is a global ID or scoped to a task. Baseline of 3 is appropriate since the schema already covers the parameter 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?
The description 'Get a specific task attachment' clearly identifies the verb (get), the resource (task attachment), and specifies 'specific' to indicate retrieval by identifier. It distinguishes from sibling tools like taiga_tasks_attachments_list (list vs get) and other attachment_get tools for epics/userstories/issues through the word 'task'.
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 does not state when to use this tool versus taiga_tasks_attachments_list or other attachment_get tools, nor does it mention any prerequisites or context (e.g., needing the attachment ID from a prior list call). It is a bare statement of what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'List' without disclosing behavioral details such as pagination, return format, or authentication requirements. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is efficient and to the point, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with a clear description and fully documented parameters. However, the lack of any information about the response structure or usage context makes it only minimally complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (Project ID, Task ID), and the description reinforces that attachments belong to a task. The description does not add meaning beyond the schema, so the baseline score of 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 clearly states the tool lists attachments of a task, using a specific verb and resource. It distinguishes from sibling tools such as taiga_tasks_attachment_get (which retrieves a single attachment) and other entity-specific attachment lists.
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 other attachment list endpoints or the single-attachment getter. It only states the action without any 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?
With no annotations, the description carries the full burden. It only indicates a write operation ('update order') but does not disclose side effects, permission requirements, expected response format, or whether the operation replaces the entire ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the core action and resource. It earns its place but is perhaps too terse, providing no extra 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?
The description is minimal and lacks behavioral context, usage guidance, or return value information. Since there is no output schema and no annotations, the description should provide more context, but it does not explain ordering semantics or prerequisites.
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 (project ID and bulk_orders as array of [id, order] pairs). The description adds no additional parameter semantics beyond what the schema provides.
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 'Bulk update order of task statuses' clearly states the action (bulk update order), the resource (task statuses), and distinguishes it from sibling tools like taiga_task_statuses_update or other bulk_update_order tools for different resource 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?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this should be used for reordering multiple statuses at once or contrast it with single status updates or other bulk order 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'get', which implies a read operation but does not mention return format, error behavior, authentication, permissions, or any side effects. For a simple read tool this is minimal, but it fails to add value beyond the 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is appropriately concise for a simple get-by-ID tool. It is front-loaded with the core purpose. However, the wording is slightly awkward ('a task statuses') and it lacks any additional clarifying structure, reducing slightly from a perfect score.
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 is simple (one fully described parameter, no output schema). The description adequately states the operation's essence for selection and invocation. It does not cover error responses or permissions, but given the low complexity and complete schema, the description is reasonably complete. It falls short of outlining return details, but those are not strictly required without an output schema.
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 fully documents the 'id' parameter with description 'ID' (100% coverage). The description does not add any additional parameter context; 'by ID' simply restates the schema. Since schema coverage is high, the baseline is 3, and the description adds no extra nuance.
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 a task statuses by ID' clearly states a singular resource (task status) and a specific verb (get). It distinguishes from list/create/update/delete siblings by indicating retrieval by ID, though it doesn't explicitly differentiate from other get tools like taiga_tasks_get. The slight grammatical error ('a task statuses') does not obscure meaning.
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 taiga_task_statuses_list or other entity-specific get tools. There is no mention of prerequisites, exclusions, or alternative tools. The only implied context is that an ID is needed, which is already evident from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does disclose an important trait: only public events are returned, which is a meaningful scope limitation. However, it omits other behavioral aspects like pagination behavior, authentication requirements, or return format, so transparency is partial.
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 one short sentence that immediately conveys the action and scope. There is no filler or redundant information. It is appropriately sized for a simple 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?
For a simple two-parameter read tool, the description provides enough to start, but it misses some context that would help in practice: it does not mention pagination defaults or how results are structured (no output schema exists). The ambiguity with taiga_timeline_user is also a gap in contextual completeness, as the agent may not know which timeline tool fits the user's request.
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 input schema provides a description for 'user_id' (50% coverage) but leaves 'page' undocumented. The tool description adds no parameter semantics beyond what the schema provides, failing to compensate for the undocumented 'page' parameter. An agent might not know how to use pagination without further hints.
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 verb and resource: 'Get timeline for a user profile'. It also specifies a scope ('public events only'), which helps set expectations. However, it does not distinguish this tool from the sibling 'taiga_timeline_user', which could easily be the same purpose, so it lacks full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'public events only' gives some context about the content delivered, but it does not provide guidance on when to choose this tool over alternatives like taiga_timeline_user or taiga_timeline_project. There is no explicit mention of conditions, exclusions, or alternative tool recommendations, leaving the agent to guess.
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 bears full responsibility for disclosing behavioral traits. It only states that it lists users and can filter by project, but it doesn't mention that it's a read-only operation, whether authentication is required, if pagination is involved, or what specific data is returned. These are significant gaps for a tool with no structured metadata.
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 consists of two short sentences that are direct and free of fluff. 'List users' is front-loaded as the primary action, and 'Filter by project' adds essential scoping without redundancy. Every word serves a purpose, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single optional parameter and no output schema, the description is minimally adequate. It conveys the core function and the filter option. However, it lacks context about the return format, pagination, authentication requirements, or whether the list represents all users or only those visible to the authenticated user. This leaves the agent with unanswered questions about the tool's behavior in real 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?
The schema fully documents the single 'project' parameter with a description of 'Project ID', covering 100% of parameters. The description's 'Filter by project' reinforces this but adds no extra detail (e.g., whether the filter is optional or required, or the effect of omitting it). Since the schema covers the parameter adequately, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List users' which identifies the action and resource, fulfilling the purpose requirement. The addition of 'Filter by project' indicates a scoping capability. However, it doesn't explicitly distinguish this from related tools like taiga_users_get or taiga_users_me, though 'list' implies a collection 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 such as taiga_users_get, taiga_users_me, or taiga_memberships_list. The description doesn't mention any prerequisites, exclusions, or explicit use cases beyond the inherent purpose, leaving the agent to infer appropriate usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it merely restates the tool name without adding any behavioral details. It does not explain side effects, idempotency, whether it replaces the entire order or partially updates, or any required permissions. This is a mutation tool, and the description offers no insight beyond the action 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 fluff. It is front-loaded with the core action and resource. However, it is almost a verbatim expansion of the tool name, which limits its informational value, though it remains appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a write operation with no annotations and no output schema. The description only states the basic purpose, which is essentially the same as the tool name. The schema covers parameters, but there is no behavioral context, example usage, or mention of responses. An agent would need to infer key details about how the bulk order update works, making the description incomplete 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 description coverage is 100%, so the baseline is 3. The parameters are described in the schema as 'Project ID' and 'Array of [id, order] pairs', which adequately explain their meaning. The tool description adds no additional parameter semantics, but the schema already provides sufficient information.
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 'Bulk update order of userstory statuses' clearly states the action (bulk update order) and the specific resource (userstory statuses), which distinguishes it from sibling tools like task_statuses_bulk_update_order or issue_types_bulk_update_order. It is a specific verb+resource statement that leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or scenarios where a different tool would be more appropriate. The differentiation from siblings is only implied by the resource name, but no explicit usage direction 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, so the description carries the full burden of behavioral disclosure. It only says 'get', implying a read operation, but gives no detail on possible errors, permissions, return format, or side effects. This is a minimal, not transparent, 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?
The description is one short sentence, directly front-loaded with the action and resource. There is no wasted verbiage, though the grammar 'a userstory statuses' is slightly awkward.
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 simple one-parameter tool and no output schema, the description is minimally viable but does not explain the return value or any domain context. It could be improved by stating that it returns a single userstory status object, but the current text is adequate for basic invocation.
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 'id' parameter is self-explanatory. The description adds no extra meaning about the ID beyond what the schema already 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('userstory statuses') with a filter by ID. It distinguishes from the sibling list tool by specifying 'by ID', though it does not elaborate on the shape of the result or define what a userstory status is.
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 for when to use this tool versus the many sibling status tools (e.g., list, create, update, delete). The 'by ID' wording implies use when an ID is available, but there is no explicit statement of appropriate context or alternatives.
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. It simply states what the tool does without disclosing any behavioral details such as read-only nature, response format, pagination, authentication requirements, or whether it includes all item types. This leaves significant ambiguity for the agent.
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, extremely concise, and directly states the purpose. Every word earns its place with no waste or unnecessary 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?
For a simple one-parameter list tool, the description is minimally adequate but incomplete in context. It does not clarify what 'items' encompasses (e.g., projects, epics, user stories) or mention pagination/response behavior. However, the low complexity and schema coverage mitigate the gap, making it acceptable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with the parameter described as 'User ID', and the tool description confirms the id is the user whose watched items are listed. This adds no new syntax or format details beyond the schema, 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 'List items watched by a user' clearly states the action (list) and the resource (items watched by a user). It distinguishes from sibling tools like taiga_users_liked and taiga_users_voted by focusing on 'watched', though it does not specify the types of items or 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 is provided on when to use this tool versus alternatives. It does not mention conditions like 'use taiga_users_liked for liked items' or any exclusions. The intended use is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. The word 'delete' implies destructive action, but the description does not state that deletion is permanent, whether associated webhook logs are affected, or if special permissions are required.
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 succinct sentence, 'Delete a webhook.', that is front-loaded and free of unnecessary words. For a tool with one clear parameter, this is appropriately 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?
For a simple one-parameter delete operation, the description plus schema is minimally viable. However, it lacks any mention of irreversibility, side effects on webhook logs, or what a successful response looks like, which would be valuable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single parameter 'id' as 'Webhook ID' and marks it as required. The description adds no additional parameter meaning, so the baseline of 3 for high schema coverage 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 'Delete a webhook' uses a specific verb and resource, and clearly differentiates from sibling webhook operations like list, create, get, update, and test. However, it is essentially a restatement of the tool name and adds no context about what a Taiga webhook is.
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 webhooks_update or disabling a webhook. There are no prerequisites, permission requirements, or consequences mentioned, leaving the agent without situational cues.
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, the description bears the full burden of behavioral disclosure. It only states 'Get a wiki page,' implying a read operation, but does not describe the return format, potential errors, authorization needs, or any other behavioral traits. This is minimal transparency even for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to conveying the tool's purpose, making it highly concise and well-structured for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter getter with no output schema, so the description is minimally adequate. However, it lacks any mention of the response structure or when to prefer this over taiga_wiki_get, leaving a small but notable contextual gap. These missing details would help an agent select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage of both parameters (slug and project), so the description adds little semantic value. The phrase 'by slug and project' simply restates the parameter names. Baseline 3 applies because the structured data is sufficient.
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 identifies the action ('Get'), resource ('wiki page'), and the lookup approach ('by slug and project'). It is distinct from likely siblings like taiga_wiki_get, but it does not explicitly name the alternative or differentiate by ID, so it falls short of a 5.
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 taiga_wiki_get or taiga_wiki_list. The description merely states what it does, leaving it to the agent to infer the appropriate context from the name and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. 'Partial' hints at the update scope, but it fails to disclose conflict-check behavior, permission requirements, error conditions, or the return value. This leaves the agent unaware of important side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately conveys the action and resource, making it easy to parse.
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 50% parameter description coverage, the minimum viable description is insufficient. An agent cannot reliably infer when to use the tool, what parameters to provide, or what to expect in response, especially for a mutation tool with conflict-check semantics.
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%; slug and content lack descriptions. The description adds minimal meaning beyond the schema by saying 'partial', but it does not explain what slug or content represent or how they are used. It fails to compensate for the undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('wiki page'), and adds 'partial' to indicate PATCH-like behavior. This clearly distinguishes it from sibling tools like create, get, and delete.
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 taiga_wiki_create or taiga_wiki_get_by_slug. It does not mention prerequisites like fetching the current version before updating or handling conflict errors.
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 present, so the description must disclose behavioral traits. It only says 'delete' without mentioning side effects, permanence, or permission requirements. This is insufficient for a destructive operation.
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 no fluff. It earns its place, though it could include more context without being overly 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 delete tool with one well-defined parameter, the description is minimally sufficient. However, it lacks context about the difference from value deletion and the irreversible nature, leaving some 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?
The schema covers the parameter fully (100%) with a description 'Custom attribute ID'. The description adds no extra meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('custom attribute definition for epic'). It distinguishes from sibling tools like update, list, get, and values 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. It doesn't mention whether this deletes the definition versus values, or any prerequisites like project membership.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action without disclosing mutation behavior, version conflict handling, partial update semantics, or error outcomes. The version parameter is mentioned in the schema but not explained in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no unnecessary words. It communicates the core purpose 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?
Despite high schema coverage, the description lacks behavioral context essential for correct use: how version conflicts are handled, whether attributes_values is a full replacement or partial update, and how to obtain the required version. No output schema exists, so the description should provide more 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?
The input schema has 100% coverage, with descriptions for id, version, and attributes_values. The description adds no additional parameter-level context beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('update') and identifies the resource ('custom attribute values for a specific epic'), clearly distinguishing it from the sibling tool that updates custom attribute definitions. It is unambiguous and immediately actionable.
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 taiga_epic_custom_attributes_values_get or taiga_epic_custom_attributes_update. There is no mention of prerequisites like retrieving the current version or that this tool updates values only, not definitions.
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 burden. It only states the operation (list) without disclosing read-only nature, permission requirements, pagination, or return structure, leaving the agent uncertain about side effects and response shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words, precisely stating the action and target resource.
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?
Without an output schema or annotations, the description offers minimal context. It does not describe the response format, possible fields, pagination, or any special behavior, which is insufficient for an agent to fully predict the tool's output.
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 'Project ID' and 'Epic ID' clearly described. The description adds no extra parameter detail, so baseline 3 is appropriate as the schema handles the parameter semantics.
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 'List attachments of an epic.' uses a specific verb (List) and resource (attachments) scoped to 'epic', clearly distinguishing it from sibling tools like taiga_epics_attachment_get (single attachment) and other resource-specific attachment listers (user stories, tasks, issues, wiki).
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. It does not mention that it lists all attachments for an epic, nor does it differentiate from taiga_epics_attachment_get or other attachment list 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?
With no annotations, the description carries full responsibility for behavioral disclosure. It mentions the comment is posted via the history endpoint, but does not disclose side effects, permissions, reversibility, or response format. As a mutation tool, 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 brief and front-loaded with the primary purpose. The second sentence about the history endpoint is somewhat vague and contains a minor grammar error ('a issue'), but overall it is appropriately sized and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only two parameters and no output schema, so complexity is low. The description covers the basic action but lacks information about return values, authentication requirements, or specific constraints. It is minimally adequate but leaves gaps for an agent to fully understand the 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?
The input schema already provides complete descriptions for both parameters (id as 'issue ID', comment as 'Comment text'). The description adds no additional meaning or constraints, so it meets the baseline for high 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 explicitly states the action ('Add a comment') and the target resource ('a issue'), making the purpose clear. It distinguishes from sibling comment tools by specifying the resource type (issue) rather than user story, task, or wiki.
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. It does not mention prerequisites, exclusions, or alternative tools for other resource types. The description only states the action without contextual usage 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. It only states the action and omits critical details for a destructive operation, such as whether deletion is permanent, whether permissions are required, or what happens if the comment or issue does not exist.
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 no filler, front-loading the verb 'Delete' to immediately convey the action. It is appropriately sized for the simple function it describes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a destructive delete operation with no annotations and no output schema, the description is insufficiently complete. It does not state whether deletion is reversible, what response to expect, or any error conditions. The parameter schema covers the 'what,' but the description misses the necessary context for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters: 'issue ID' and 'Comment ID (from history).' The tool description does not add any additional meaning about parameter usage, such as how to retrieve the comment_id from history. Since schema coverage is 100%, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Delete a comment from a issue.' It specifies the resource (comment) and the container (issue), which distinguishes it from sibling comment deletion tools for user stories, tasks, and wiki pages. 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?
The description offers no guidance on when to use this tool versus alternatives such as taiga_userstory_comment_delete or taiga_wiki_comment_delete. It simply restates the action implied by the tool name, without mentioning prerequisites, exclusions, or alternative selection criteria.
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 only states the action without detailing the response format, authentication needs, potential read-only nature, or whether the history includes comments, changes, or both. This is insufficient for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. It is efficient with no fluff, though it is slightly under-specified, earning a 4 rather than 5.
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-only tool with one parameter and no output schema, the description gives a minimum viable level of information. However, it lacks any indication of the return structure or additional context (e.g., ordering, pagination) that would help an agent fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a clear description ('issue ID'), so the baseline is 3. The description reinforces the meaning by saying 'for a issue' but adds no additional semantic detail beyond what the schema already provides.
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 'Get change history for a issue.' clearly states the verb (Get) and the resource (change history for an issue), which distinguishes it from sibling history tools like taiga_userstory_history and taiga_task_history by specifying the issue entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or cases where another tool like taiga_issue_comment_create might be more appropriate for fetching issue-related activity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It fails to mention that deletion is permanent, may have cascading effects on related data, or requires permission, which is critical for destructive operations.
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 concise and front-loaded, with no wasted words. It is appropriately sized for a simple tool, though it skips behavioral details that might be expected.
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 one parameter and no output schema, the description names the action and resource adequately. However, it lacks any mention of side effects, irreversibility, or failure scenarios, which are important for a delete operation, and no annotations fill that 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?
The schema fully documents the only parameter 'id' with description 'Issue ID' (100% coverage). The description itself adds no additional meaning beyond naming the action, so the baseline score of 3 applies.
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 'Delete an issue.' uses a specific verb and resource, clearly indicating the action. It distinguishes itself from sibling issue tools like taiga_issues_get, taiga_issues_update, and taiga_issues_list by focusing on deletion.
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, no exclusions, and no context about prerequisites. It merely states the action without explaining appropriate scenarios.
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 mention whether the operation is idempotent, whether authentication is required, side effects on vote counts, or reversibility. The description adds no behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded and easy to parse, achieving maximum 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?
For a mutation tool with no annotations and no output schema, the description is too sparse. It does not cover authentication requirements, idempotency, or what happens if the user has not voted. The schema covers only the parameter, leaving important operational context 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 a single 'id' parameter described as 'Issue ID'. The description adds no additional parameter semantics, but the schema already sufficiently documents the parameter, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove vote') and a clear resource ('an issue'), distinguishing it from sibling downvote tools for epics, user stories, and tasks, and from the corresponding upvote tool. The meaning 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?
The description offers no guidance on when to use this tool versus alternatives, no prerequisites (e.g., user must have already voted), and no exclusions. It merely states the action without 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?
With no annotations present, the description carries the full burden of disclosing behavior. It implies a read-only operation through 'Get' but does not describe the response format, authentication needs, or any side effects. This is minimal and leaves much unspecified.
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 short sentence that delivers the core purpose without filler. It is exactly as concise as needed for a one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, so the description should compensate by explaining what 'filters data' entails or when it should be used. It does not, leaving the return value and purpose ambiguous for an agent.
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 describes the only parameter 'project' as 'Project ID' with 100% coverage. The description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('filters data for issues in a project'). It distinguishes this tool from siblings like taiga_tasks_filters_data or taiga_issues_list by naming 'issues' explicitly.
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 taiga_issues_list or taiga_projects_issues_stats. The intended use case for 'filters data' is not explained beyond the literal 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 present, so the description carries the full burden for behavioral transparency. It only states the action and a filter, without disclosing that this is a read-only operation, mentioning pagination, ordering, or describing the return payload. The agent is left without expectations for side effects or output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler, front-loading the action and adding only the key filter. It is appropriately sized for a simple list tool and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is terse: it omits return format, pagination, and any behavioral details. It is barely adequate for a simple list, leaving enough gaps that an agent cannot fully predict the tool's behavior or response.
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?
Both parameters are already fully described in the schema ('Filter by closed status' and 'Project ID'), and the description's 'Filter by project' adds no new semantic detail. With 100% schema coverage, the description provides no significant parameter insight beyond what the schema already offers.
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 ('List') and identifies the resource ('milestones/sprints'), making the action clear. It notes an optional filter by project, but does not explicitly differentiate this from sibling tools like taiga_milestones_get or taiga_milestones_stats, though the 'list' verb itself helps.
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 a straightforward listing use case with optional project filtering, but provides no explicit guidance on when to use this tool versus alternatives (e.g., getting a single milestone or viewing stats). It lacks exclusions or alternative tool references, so usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing behavior. The verb 'Get' clearly indicates a read-only operation, which is helpful, but it doesn't mention response format, error handling, or permissions. It's minimally transparent for a simple getter.
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, front-loaded sentence that gets to the point. The grammar error 'a priorities' slightly detracts, but overall it is appropriately concise for a simple getter.
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 one parameter and no output schema, the description is minimally adequate. The agent can infer the operation and parameter, but it lacks details about the return value or any potential caveats, making it just acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of the only parameter ('id' as number with description 'ID'). The description's 'by ID' merely restates the schema without adding any extra semantic meaning.
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 ('Get') and the resource ('priorities') with an ID parameter, distinguishing it from list operations. However, the grammar is awkward ('a priorities') and it doesn't provide context about what a priority is in Taiga.
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 taiga_priorities_list or other getters. The description implicitly suggests using it when you have a specific ID, but this is not explicitly 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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'Delete a project,' implying a destructive action, but does not state whether it is permanent, whether it cascades to related entities (epics, user stories, tasks), or whether special permissions are required. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the action and the required identifier. Every word earns its place, with no redundancy or filler. It is appropriately sized for a simple one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has only one parameter and no output schema, it is destructive. The absence of any note about permanence, side effects, or authorization makes the description incomplete for safe and correct use. For a delete operation, the context is not sufficiently covered by the schema or annotations.
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% because the only parameter 'id' is already described as 'Project ID.' The description's phrase 'by its ID' merely rephrases the schema and adds no extra information about format, constraints, or usage. Baseline 3 is appropriate when the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'project' with the means of identification ('by its ID'). It distinguishes from sibling tools like taiga_projects_update, taiga_projects_get, and taiga_projects_create, and even from taiga_projects_delete_tag which deletes a different entity.
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, no prerequisites, no exclusions, and no warning about irreversibility. For a destructive operation, some usage context should be provided, such as verifying the project ID first or noting that deletion may have 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, and the description only states the action without disclosing effects such as idempotency, authentication requirements, or what happens if the project is not liked. The term 'Unlike' implies a state change but lacks detail.
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 brief (4 words) and gets to the point. However, it adds little beyond the tool name, though the brevity is appropriate for a simple one-parameter action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, yet the description omits behavioral details that would be relevant for a mutation tool. Given the low complexity, the description is adequate but minimal; siblings like taiga_projects_like provide contrast.
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 fully documents the single 'id' parameter with its description 'Project ID', so the description adds no further parameter detail. With 100% 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Unlike a project.' uses a specific verb and resource, clearly identifying the action. The sibling tool taiga_projects_like provides a direct contrast, making the purpose distinguishable.
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 or alternatives is provided. The description merely restates the tool's function without contextual cues 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?
With no annotations provided, the description must disclose behavioral traits. It adds '(partial)' which hints at PATCH-like semantics, but it does not explain how missing fields are handled, whether the permissions array is replaced or merged, or any authentication or side-effect 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 an efficient single sentence, front-loaded with the action. Every word adds meaning, though it is so brief that it borders on under-specification rather than concise completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 5 parameters, no annotations, no output schema, and minimal description. The description is far too sparse to guide correct invocation, leaving the agent to guess about parameter meanings, update semantics, and response format.
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 'id' is described). The description itself does not explain any parameters. Field names like 'order' and 'computable' are ambiguous, and the tool 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a role (partial)' clearly states a specific verb and resource, and the 'partial' qualifier distinguishes it from a full replacement. The sibling tools include roles_create, roles_get, and roles_delete, making this uniquely the update 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?
Usage is implied by the verb 'update' – if you need to modify an existing role, this is the tool. However, there is no explicit guidance about when to prefer this over create from roles_create or any prerequisites like needing the role ID 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. It states only that history is retrieved but does not disclose response format, ordering, pagination, or whether the history includes field changes versus comments. This lack of behavioral detail leaves the agent uncertain about the tool's output.
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 no filler, efficiently conveying the core function. It is front-loaded and optimally 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?
With no output schema and no annotations, the description is too sparse. It does not explain what the returned history contains, how to interpret entries, or whether there are any limitations. For a history endpoint, the agent would need more context to effectively use the result.
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 covers 100% of parameters with the description 'task ID'. The tool description adds no additional meaning beyond the schema, but the high schema coverage meets the baseline for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'change history for a task'. It distinguishes from sibling history tools like taiga_userstory_history, taiga_issue_history, and taiga_wiki_history by explicitly limiting scope to tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this returns a task's audit trail, contrast with taiga_tasks_get, or clarify that comments are handled elsewhere (e.g., taiga_task_comment_create).
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, the description carries the full burden of behavioral disclosure, but it only states the verb 'delete' without explaining consequences such as permanence, permission requirements, or cascading effects. It does not disclose what happens to associated attachments or comments, nor the response format.
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 efficiently communicates the tool's purpose without extraneous information. It is appropriately sized for a simple delete operation.
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?
Although the schema covers the parameter, the description provides no context about the operation's side effects, irreversibility, or required permissions. For a destructive delete action with no annotations or output schema, the description is incomplete and leaves the agent guessing about the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single required parameter 'id' as 'Task ID', giving 100% coverage. The description adds no additional information about parameter semantics, so the baseline score of 3 applies given the schema's clarity.
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 'Delete a task' clearly states the action (delete) and the target resource (task), distinguishing it from sibling tools like taiga_tasks_list, taiga_tasks_get, and taiga_tasks_update. It is specific and unambiguous despite being 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, irreversible nature, or that taiga_tasks_delete is the appropriate choice when permanently removing a task. No exclusions or context 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core action 'Stop watching a task' and does not mention side effects, idempotency, permissions, or what happens if the user is not watching the task. The behavior is essentially identical to what the tool name already implies.
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 waste. It is front-loaded and directly states the action, making it easy to parse.
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 tool with one parameter and no annotations or output schema, the description is too brief. It does not explain the effect on the task's watch status, any return value, or prerequisites such as needing to be a current watcher. This leaves significant gaps for the agent.
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 parameter 'id' described as 'Task ID'. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stop watching a task.' clearly identifies the verb (stop watching) and the resource (task), distinguishing it from sibling tools like taiga_tasks_watch and taiga_tasks_watchers. The purpose is immediately understandable.
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, nor any exclusions or prerequisites. It merely restates the action without mentioning that it applies to tasks the user is currently watching, nor contrasting it with the watch or watchers 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'list', which implies a read operation, but does not describe the return format, whether pagination is involved, authentication requirements, or any other behavioral details. The description adds minimal context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. Every word earns its place, and there is no unnecessary filler or repetition.
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 tool with one parameter, no annotations, and no output schema, the description is minimally adequate. It explains the core function and parameter mapping, but it omits context such as what constitutes a 'contact', whether the list is scoped to a project, or any expected response structure. This leaves meaningful gaps for an agent attempting to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes 'id' as 'User ID' (100% coverage), but the description adds crucial meaning by linking it to 'a user' whose contacts are listed. This clarifies that the parameter is the user whose contact list is being retrieved, going beyond the schema's minimal description.
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 'List contacts of a user' uses a specific verb ('list') and resource ('contacts of a user'), clearly distinguishing it from sibling tools like taiga_users_get (get user details) and taiga_users_list (list users). However, it does not explicitly differentiate itself by describing what 'contacts' means in this context, so it stops short of a 5.
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 taiga_users_get or taiga_users_list. There are no explicit use cases, prerequisites, or exclusions, leaving the agent to infer usage solely from the name and brief description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure, but it only states the action without addressing permanence, authentication needs, or side effects. The verb 'delete' implies destructiveness, but the description does not confirm whether the action is irreversible or what happens on success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every word ('Delete', 'comment', 'userstory') contributes to conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too thin: it omits return-value expectations, error conditions, and whether deletion is permanent. While the parameters are well-documented in the schema, the surrounding operational context 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 the schema already documents both parameters ('userstory ID' and 'Comment ID (from history)'). The description adds no additional parameter meaning, which matches the baseline of 3 for high 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 'Delete a comment from a userstory.' uses a specific verb (delete) and identifies a precise resource (a comment on a userstory), clearly distinguishing it from sibling tools like taiga_userstory_comment_create and taiga_task_comment_delete. The action and target are 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?
The description provides no guidance on when to use this tool versus alternatives; it only states the core action. There is no mention of exclusions, prerequisites, or reference to sibling comment-deletion tools for other entity types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only operation via 'Get' and identifies the object returned, but it does not disclose response format, authorization requirements, or error behavior. For a simple get-by-id, this is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler, but it repeats 'userstory' and 'get' from the tool name. The only genuinely new information is 'definition,' making it slightly redundant. Still, it is efficiently short.
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 (one parameter, no output schema, no annotations), which lowers the burden. The description gives the essential purpose but leaves the return structure and any behavioral nuance to inference. It is complete enough for a basic fetch but lacks explanatory detail that would help an agent anticipate the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description for the single 'id' parameter ('Custom attribute ID'), so baseline is 3. The description adds no extra meaning about the parameter, and the wording 'for userstory' could be misread as implying the id belongs to the userstory rather than the attribute, though schema clarifies 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 clearly states the tool gets a custom attribute definition for a userstory, using the specific verb 'Get' and naming the resource. It distinguishes from sibling tools like those for epics/tasks/issues and from values_get, though it doesn't elaborate on what 'definition' entails.
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 the list tool or values_get. The description simply states the action without mentioning prerequisites, selection criteria, or when a different tool would be more 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. It only says 'Update a custom attribute definition' without disclosing mutation behavior, partial vs full update, permission requirements, or effects on existing data. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words, making it concise and front-loaded. However, it could be slightly more informative 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 5 parameters, no output schema, and no annotations, the tool requires more context. The description fails to mention that only 'id' is required, that other fields are optional, that the tool returns the updated definition, or how it differs from updating custom attribute values. This is a significant gap.
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 'id' is described). The description does not explain that 'name', 'type', 'order', and 'description' are updatable fields or how they relate to the custom attribute definition. It adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Update') on a specific resource ('custom attribute definition for userstory'), which distinguishes it from sibling tools like create, delete, get, and from custom attribute updates for other entities (epic, task, issue).
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 when updating an existing userstory custom attribute definition, but lacks explicit guidance on when not to use it (e.g., for updating attribute values, which have separate tools like taiga_userstory_custom_attributes_values_update). No 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 burden for behavioral disclosure. It says 'Update' but does not state that this overwrites the entire map of attribute values, that a version is required for optimistic locking, or what happens on version conflict. No side effects, error behavior, or permission requirements are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the action and target with no filler. With only one sentence, it is maximally concise while still being meaningful.
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, this description is too thin. It omits critical context about the version field's role in conflict checking, whether omitted attributes are cleared, and what the API returns. The description should explain the update semantics and conflict/error behavior to compensate for missing structured context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents all three parameters with descriptions (id, version, attributes_values). The description adds no extra semantics beyond what the schema already provides, so the baseline 3 is appropriate given 100% 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 clearly states the action ('Update') and the resource ('custom attribute values for a specific userstory'). This distinguishes it from sibling tools that update custom attribute definitions (e.g., taiga_userstory_custom_attributes_update) or update values for other entity types (tasks, epics, issues).
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 taiga_userstory_custom_attributes_values_get or taiga_userstory_custom_attributes_update. It does not mention the version-based concurrency control or any prerequisites, making it unclear when a version value is needed.
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, the description carries the full burden but only states the action. It doesn't disclose potential side effects (e.g., immediate activation), required permissions, or that the key is sensitive. This is barely more informative than the tool name.
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 unnecessary words. It is front-loaded and efficient, though it sacrifices helpful context for brevity.
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 create operation with fully documented parameters, the description is passable but minimal. It lacks output/response details and any behavioral caveats, but the schema and sibling tool names provide some 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%, so the schema fully documents all four parameters. The description adds no additional semantic detail, but since the schema already covers this, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new webhook' uses a specific verb and resource, clearly distinguishing it from sibling tools like taiga_webhooks_list, taiga_webhooks_update, and taiga_webhooks_delete.
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. It doesn't mention that this is for creating new webhooks while other tools handle listing, updating, or testing 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, the description carries full responsibility for disclosing behavior. It only states the action 'Delete a wiki page' without mentioning permanence, side effects on attachments or history, permissions required, or what happens on success or failure. This is minimal behavioral disclosure for a destructive operation.
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, clear sentence with no redundant wording. It is appropriately minimal for a simple delete operation and is easy to parse at a glance.
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?
As a mutation tool with no annotations, no output schema, and an extremely brief description, it fails to clarify the consequences of deletion—such as irreversibility, impact on linked resources, or response behavior. This leaves the agent without essential context for a destructive action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter 'id' as 'Wiki page ID', providing 100% schema description coverage. The description adds no further meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete' and the resource 'wiki page', which is specific and distinguishes it from sibling tools like taiga_wiki_create, taiga_wiki_get, and taiga_wiki_update. The verb+resource combination unambiguously identifies the tool's 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?
There is no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, conditions, or related operations, leaving the agent without context for choosing this tool over other wiki actions.
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, the description carries the full burden for behavioral disclosure. It only states the operation, omitting whether it's read-only, what the history entries look like, or any pagination/filtering behavior.
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?
Six words, zero filler. All claims are relevant and front-loaded, making it highly 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?
Description is minimal for a tool with no output schema. It does not describe the structure of the returned history, any ordering, or limits, leaving the result format to be inferred.
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 'id' is fully described in the schema as 'wiki ID' (100% coverage). The description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('wiki') with scope ('change history'), distinguishing it from sibling read tools like taiga_wiki_get and taiga_wiki_list.
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 does not mention any required context, exclusions, or fallback tools, leaving the agent to infer appropriate usage.
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 present, so the description carries the full transparency burden. It only states 'Get', which implies a read-only operation, but does not mention authorization requirements, return format, or any effect on data. It adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the purpose, with no wasted words. It fits the expected format for a simple 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 one-parameter getter, the description is minimally adequate. It clearly names the resource and the schema covers the parameter. However, it lacks any mention of response contents or prerequisites, and no output schema exists. It is not egregiously incomplete but could add a hint to use the list endpoint.
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 provides 100% coverage for the single 'id' parameter, described as 'Attachment ID'. The description adds 'epic attachment' context but does not explain param format or how to obtain the ID. Baseline 3 is appropriate because the schema already handles parameter semantics.
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 'Get a specific epic attachment' uses a specific verb and resource, clearly indicating it retrieves a single attachment by ID. It distinguishes from sibling list tools and other attachment getters by explicitly naming 'epic attachment'.
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 taiga_epics_attachments_list or attachment getters for other object types. The description implies usage when you have a specific attachment ID but does not state exclusions or alternatives.
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, the description carries the full burden of behavioral disclosure. 'Delete an epic' implies a destructive operation but fails to mention permanence, effects on related user stories, permission requirements, or response behavior, leaving significant uncertainty for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At three words, the description is extremely concise and front-loaded. It communicates the essential action with zero wasted words, which is ideal for a simple delete 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?
Given the simplicity of a one-parameter delete tool, the description is minimally adequate, but it omits important behavioral caveats such as irreversibility, side effects on related entities, or permissions. The lack of annotations and output schema makes this a clear gap, yet the core function is identifiable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single 'id' parameter (number, 'Epic ID'), so the baseline score is 3. The tool description adds no additional parameter semantics, but the schema alone is sufficient.
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 'Delete an epic.' uses a specific verb (delete) and a clear resource (epic), which unambiguously differentiates it from sibling tools like taiga_epics_update or taiga_epics_create. It leaves no doubt about the tool's action and target.
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, no exclusions, and no context. It simply states the action without any elaboration on appropriate use cases 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?
With no annotations, the description carries the full burden of behavioral disclosure. It indicates a mutation ('Remove') but fails to explain consequences, such as whether the user story is deleted, whether the operation is reversible, or any permission prerequisites.
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 that conveys the core action without any filler. Every word contributes to the meaning, and it is 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?
For a simple 2-parameter mutation with no output schema and no annotations, the description is minimally adequate. It covers the action and parameters but omits side-effect context and return behavior, leaving some ambiguity about the exact effect of the 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?
The input schema fully documents both parameters with descriptions ('Epic ID', 'User Story ID'), achieving 100% coverage. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a user story from an epic.' clearly states the action, the target resource (epic), and the object (user story). It distinguishes itself from sibling tools like add, list, and bulk_create for related user stories, and from userstory deletion.
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. It does not clarify that only the association is removed and the user story itself is not deleted, nor does it reference related operations such as add or bulk_create.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. The verb 'Get' implies a read operation, which is a positive signal, but the description does not mention error behavior, authentication needs, or the shape of the returned definition. It is minimally transparent but leaves room for assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste. Every word contributes to the meaning, and it avoids repeating what the name or schema already convey.
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 getter with one parameter, the description is enough to understand the basic operation, but it lacks detail about the return payload or how it differs from the values endpoints. Since there is no output schema, a little more context 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?
The schema already provides 100% coverage for the single parameter 'id' with 'Custom attribute ID'. The description adds no additional parameter context, so the baseline of 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a custom attribute definition for issue' clearly states the verb and resource, and it distinguishes from sibling tools by specifying 'issue' rather than epic, userstory, or task. It is slightly less specific than it could be about the return payload, but the core 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 on when to use this tool versus alternatives like the list or values endpoints. There are no exclusions, prerequisites, or contextual hints about how this tool fits into a workflow, so the agent must infer usage solely from the name.
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 disclose behavioral traits. It only states the basic operation and provides no information about return format, pagination, ordering, or access implications. The read-only nature is implied but not explicitly stated.
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 is front-loaded with the verb and resource. Every word earns its place, with no redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters and no output schema, but the description is minimal. It does not clarify what the response contains or any edge-case behavior, which could be expected given the lack of annotations and output schema.
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 'project' and 'object_id' documented. The description adds no additional semantic meaning beyond what the schema already provides and the phrase 'of an issue' which maps object_id to an issue.
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 'List attachments of an issue' clearly identifies the action (list) and the resource (attachments of an issue), which is distinct from single-attachment retrieval tools and other attachment-list tools for different objects. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like taiga_issues_attachment_get or other attachments_list tools. It does not mention exclusions, prerequisites, or scenarios, leaving the agent without explicit usage 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'List' implies a read-only operation, but the description does not disclose return format, pagination, authentication requirements, or any other behavioral traits. It adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clearly worded sentence that immediately states the function. It is front-loaded and contains no unnecessary words, making it appropriately sized for a simple one-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?
The tool is simple (one parameter, no output schema), and 'List voters of an issue' conveys the core action. However, it lacks any detail about the return value (e.g., what voter information is included) and does not provide usage context. It is minimally viable but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with a single parameter 'id' described as 'Issue ID'. The description's phrase 'of an issue' aligns with the schema but does not add any new semantics. Since schema coverage is high, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List voters of an issue' uses a specific verb ('List') and clearly identifies the resource (voters of an issue). It distinguishes itself from similar voter tools for epics, user stories, and tasks by explicitly naming 'issue' as the target resource.
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 taiga_epics_voters or taiga_tasks_voters. It does not mention any prerequisites, exclusions, or alternative scenarios. The only implied usage is that it is for issues, based on the name.
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 only states the action ('Bulk update order') without explaining effects such as whether all issue types are reordered, reversibility, permission requirements, or response format. This is minimal beyond the mutation 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?
The description is a single sentence that is front-loaded and contains no filler or redundant information. It is appropriately concise for a simple bulk order 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?
Given the tool's simplicity, the schema covers parameters, and the action is clear. However, the absence of annotations and lack of behavioral context (e.g., scope of reorder, impact on existing orders) leaves gaps. It is adequate for a basic tool but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the schema describes 'project' as Project ID and 'bulk_orders' as Array of [id, order] pairs. The description adds no additional parameter meaning, but the baseline is 3 because the schema already provides sufficient parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Bulk update') and clearly identifies the resource ('order of issue types'). This distinguishes it from singular update tools like taiga_issue_types_update and from bulk order updates for other entities (e.g., statuses, priorities).
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 context is provided. The description does not indicate when to use this tool over alternatives, nor does it mention prerequisites or exclusions. Sibling tools with similar purposes are not 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?
There are no annotations, so the description must disclose behavioral aspects. It only says 'Create a membership' without mentioning side effects like email invitations, permission requirements, or error conditions when the user already exists or the role is invalid.
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 is front-loaded with the action. No unnecessary words or repetition, earning a high score for 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 simple create operation with three self-documenting parameters, the description is minimally viable. However, with no annotations or output schema, it lacks details on implications (e.g., whether an invitation email is sent, if membership is immediate) and does not fully cover the operation's context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all three parameters (project, role, username), so coverage is 100%. The description's parenthetical 'invite user to project' adds minor context to the parameters but does not significantly enhance understanding beyond the schema.
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 'Create a membership (invite user to project)' clearly states the action and the specific resource. It distinguishes this tool from other membership operations like list, get, update, delete, and bulk_create by focusing on the singular creation of a membership.
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 taiga_memberships_bulk_create or how to handle existing users. The description merely states what it does without any prerequisites, use-case 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?
With no annotations, the description must disclose behavioral traits itself. It only states the action 'change role' but does not mention side effects, permission requirements, reversibility, or what happens if the membership or role ID is invalid. No output or error behavior is described. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It communicates the essential purpose efficiently, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two fully documented parameters, and the description states its purpose. However, no usage guidance, side effects, or return format are described, and there are no annotations to fill these gaps. It is adequate for basic invocation but misses contextual details, making it a minimum-viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides descriptions for both parameters ('Membership ID' and 'New role ID') with 100% coverage, so the description adds no extra meaning beyond the schema. The phrase 'change role' reaffirms the role parameter but does not provide additional semantics, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Update' with resource 'membership' and clarifies the action as 'change role', distinguishing it from sibling membership tools (create, delete, get, list) and other project tools. It clearly states what the tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for modifying an existing membership's role, nor does it contrast with create/delete/list. No prerequisites or context (e.g., need for admin permissions) 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 is the only source of behavioral info. 'Stop watching' implies a mutating operation but doesn't disclose side effects (e.g., whether it's idempotent, what happens if the user isn't watching, whether watcher counts are affected). It lacks details that would prepare an agent for errors or state changes.
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, tightly-worded sentence with no wasted words. It's front-loaded and easily scannable, making it an example of good conciseness, though it's minimal.
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 tool's simplicity, the description is somewhat adequate, but it lacks context about the operation's effects, error cases, and relationship to watch/watchers siblings. There's no output schema or annotations to fill in these gaps, so an agent may not know how to handle edge cases.
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 fully describes the single parameter 'id' as 'Milestone ID', and the description adds nothing beyond this. Since schema coverage is 100%, the baseline of 3 applies; the description doesn't enrich the semantics further.
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 'Stop watching a milestone.' clearly identifies the action (stop watching) and the resource (milestone). It distinguishes itself from sibling tools like 'watch' and 'watchers' through the explicit verb, making it 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as being a current watcher, or contrast with 'taiga_milestones_watch' or 'taiga_milestones_watchers'. The context is purely inferred from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It does reveal that updates are partial, which is a meaningful behavioral trait beyond a generic 'update'. However, it does not mention permissions, error behavior, or whether the updated milestone is returned, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded with the action and resource. It is free of filler and every word adds value, particularly the 'partial' qualifier which conveys important update semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no annotations, and no output schema, the description is insufficient. It does not explain return values, parameter semantics, or any necessary context such as authentication or idempotency. More detail is needed for an agent to use this tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17%, and the description provides no additional parameter information. It does not mention any of the five undocumented parameters (name, closed, disponibility, estimated_start, estimated_finish). The description contributes nothing to help an agent understand the meaning or format of these fields.
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 'Update a milestone/sprint (partial)' clearly states the action (update) and the resource (milestone/sprint), with 'partial' adding useful specificity about PATCH-like semantics. This distinguishes it from sibling tools like taiga_milestones_create, taiga_milestones_get, and taiga_milestones_delete.
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?
Usage is implied: this tool is for modifying existing milestones. However, there is no explicit guidance on when to use it versus alternatives, and no exclusions are mentioned. The 'partial' hint suggests partial updates, but it does not elaborate on when full vs partial updates should be used.
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, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not mention whether this is a read-only operation, any required permissions, pagination behavior, or the structure of the returned list. This lack of detail is a significant gap for an unannotated read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is directly front-loaded with the action and resource. It contains no filler or redundant information, achieving maximum conciseness for a simple list 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?
The tool is simple (one parameter, no output schema), and the description covers its basic purpose. However, it lacks any context about the concept of 'fans', potential pagination, or relationship to other tools. For a low-complexity tool, this is minimally viable but not fully helpful.
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 'id' described as 'Project ID'. The tool description adds the context that the list pertains to a project, but does not meaningfully extend beyond the schema. The baseline of 3 is appropriate given the high 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 'List fans of a project' uses a specific verb ('List') and resource ('fans of a project'), making the tool's function immediately clear. It distinguishes from sibling tools like taiga_projects_watchers, as 'fans' is a distinct concept, and there is no ambiguity in the 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?
There is no guidance on when to use this tool compared to alternatives. The description provides no exclusions or contextual use cases, leaving the agent without criteria to choose this over similar tools like taiga_projects_watchers or taiga_projects_get.
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, the description carries full burden. It only states the action without disclosing side effects, idempotency, authentication requirements, or error cases. For a state-changing operation, more disclosure is expected.
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 no wasted words. It is front-loaded and appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally viable. It lacks behavioral context like side effects or prerequisites, but the action is clear enough for a straightforward unwatch 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?
The schema description coverage is 100% ('Project ID' for the sole id parameter). The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stop watching a project.' uses a specific verb (stop watching) and a clear resource (project), making the action unambiguous. It distinguishes naturally from sibling tools like taiga_projects_watch and taiga_projects_watchers.
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 unlike or other unwatch tools for different entities. The name is self-explanatory, but the description lacks explicit 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. It only states 'Delete a comment from a task' without mentioning irreversibility, permission requirements, or what happens if the comment or task does not exist. This is a meaningful gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is directly front-loaded with the action and resource. Every word is necessary and there is no fluff or redundant content.
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 delete tool with full schema coverage, the description is minimally sufficient. However, it lacks any behavioral context (e.g., irreversibility) or usage guidance, and there is no output schema to clarify the response, leaving the description just barely adequate.
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 both parameters (id as task ID and comment_id as Comment ID from history) are already documented in the schema. The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and the resource 'a comment from a task', clearly stating the tool's purpose. It distinguishes from sibling comment deletion tools by specifying the resource type (task vs. userstory or issue).
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. Sibling tools like taiga_userstory_comment_delete and taiga_issue_comment_delete exist, but the description does not mention that this is specifically for task comments or provide any exclusion criteria.
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, and the description only states the action without covering important behavioral details. It does not disclose idempotency, authentication requirements, or what happens when the user has not voted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the intended meaning.
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 one-parameter action, the description is minimally adequate. However, it lacks behavioral context such as idempotency, return value, or side effects, and there are no annotations or output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter 'id' as 'User Story ID' (100% coverage). The description adds no extra meaning, but the schema already carries the necessary semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('user story'), clearly stating the action. It naturally distinguishes this tool from related siblings like taiga_userstories_upvote and taiga_userstories_voters.
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 taiga_userstories_upvote or taiga_userstories_voters. There is no mention of prerequisites like having previously voted.
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 present, so the description must disclose behavior. It only states the action without describing the return format, authentication needs, or side effects, offering minimal transparency beyond the literal function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous content. It is concise and efficient for a simple GET 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 one-parameter tool, the description is adequate but minimal. It does not state what is returned or provide additional context, though the schema covers the parameter and the purpose is clear. It meets the minimum viable threshold.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single 'id' parameter as 'User Story ID' with 100% coverage. The description merely says 'by ID', adding no 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a user story by ID', specifying the verb, resource, and identifier method. It distinguishes itself from sibling tools like taiga_userstories_list, taiga_userstories_get_by_ref, and taiga_userstories_create.
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. It does not mention exclusions or alternatives, leaving the agent to infer usage solely from the tool name and parameter 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 the full burden of behavioral disclosure. It only states the action without mentioning idempotency, prerequisites (e.g., currently watching), or potential side effects, leaving significant behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is appropriately sized for the simplicity of the tool and front-loads the core 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 single-parameter tool, the description is minimally viable but lacks contextual details such as return behavior, idempotency, or authentication requirements. Without annotations or an output schema, the description is the sole source of context and could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes one parameter, 'id', described as 'User Story ID', with 100% coverage. The description adds no additional meaning to the parameter, so the baseline score of 3 applies.
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 'Stop watching a user story' uses a specific verb ('stop watching') and a clear resource ('user story'), distinguishing it from watch, watchers, and unwatch for other resource 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 provides no guidance on when to use this tool versus alternatives, such as taiga_userstories_watch or unwatch tools for other resources. Usage is only implied by the verb and resource, with no explicit 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 must carry the behavioral burden. It simply states 'List watchers of a user story' without disclosing return format, pagination, permissions, or read-only status. While 'List' implies a read operation, the description adds no behavioral context beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It front-loads the verb and resource clearly and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and no annotations, the description is minimal but functional for identifying the tool's purpose. However, it lacks any detail about return value shape, authentication, or related operations, which an agent might need for correct invocation. It is 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?
The input schema already documents the single parameter 'id' as 'User Story ID' with 100% coverage. The description confirms that it lists watchers for a specific user story but does not add syntax, format, or usage details beyond the schema. Meets the baseline for high 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 clearly states the tool's function: 'List watchers of a user story.' It uses a specific verb ('List') and a specific resource ('watchers of a user story'), which distinguishes it from sibling tools that list watchers for other entities (epics, tasks, issues) and from voter/upvote tools. The scope is unambiguous despite being concise.
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 vs. alternatives. There is no mention of related tools like taiga_userstories_watch/unwatch or taiga_userstories_voters, nor any prerequisites or scenarios. The description only states what it does, not when to use it.
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 convey behavior. It only says 'Delete', which implies mutation but does not disclose consequences such as irreversibility, impact on user story values, or permission requirements. This is a significant gap for a destructive operation.
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 directly states the action and target. No wasted words, perfectly front-loaded and easy to parse.
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 delete tool, the purpose and parameter are clear. However, the lack of annotations and output schema means the description should provide more behavioral context (e.g., permanent deletion, effects on associated values). It is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a clear description for the 'id' parameter ('Custom attribute ID'). The tool description adds no additional parameter semantics, but the schema fully documents the only parameter, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a custom attribute definition for userstory', using a specific verb and resource. It distinguishes itself from sibling tools like update, get, and list for the same entity.
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 vs alternatives, no prerequisites or exclusions. The use is implied by the verb 'Delete' but there is no contextual direction or mention of better-suited alternatives (e.g., updating or deactivating).
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. While 'Get' implies a safe read operation, the description adds no context about return shape, permissions, or behavior when the userstory is not found. It offers no more than the tool name already conveys.
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 clear sentence with no unnecessary words. It is well-structured and immediately understandable.
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 getter with one parameter and no output schema, this is minimally adequate. It states the core action but omits usage context, return value details, and any differentiation from similar tools. The lack of annotations raises the need for more behavioral detail, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – the id parameter is described as 'userstory ID'. The description's 'specific userstory' adds little beyond the schema. Baseline 3 is appropriate since the schema already documents the parameter.
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 'Get custom attribute values for a specific userstory' uses a specific verb ('Get') and resource ('custom attribute values' for a 'userstory'), clearly distinguishing it from sibling tools like taiga_userstory_custom_attributes_get (which gets the attribute definition) and the update/create variants.
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 does not mention that this is for reading values as opposed to definitions, nor does it reference sibling tools for epics/tasks/issues that likely have analogous functions.
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 present, so the description carries full responsibility for disclosing behavioral traits. It only says 'Delete', which implies destructiveness, but does not mention permanence, permission requirements, or effects on wiki history. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is perfectly concise and structured for quick comprehension.
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 a simple delete operation with two well-described parameters, but the description lacks any context about return values, side effects, or usage scenarios. Given no output schema and no annotations, the description is minimally 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?
The input schema already provides descriptions for both parameters (id: 'wiki ID', comment_id: 'Comment ID (from history)'), giving 100% coverage. The description adds no additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a comment from a wiki'), distinguishing it from siblings like taiga_wiki_delete (deletes a wiki) and taiga_wiki_comment_create (creates a comment). It is unambiguous and specific.
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 exclusions, prerequisites, or explicit comparisons to similar comment-delete tools for other entities (e.g., tasks, issues). The context is only implied by the tool name and terse description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention return format, required permissions, error conditions, or any side effects. The description is limited to the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no filler, and the key information is front-loaded. It is as concise as possible for a simple get 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?
Given the simplicity of the tool (one parameter, no nested objects), the description is minimally viable. However, there is no output schema and no mention of the return value, which leaves some uncertainty about the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter (id: 'Wiki page ID'), achieving 100% schema description coverage. The description's 'by ID' adds nothing beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb (Get), resource (wiki page), and unique identifier (by ID). This distinguishes it from sibling tools like taiga_wiki_list and taiga_wiki_get_by_slug.
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?
Provides no explicit guidance on when to use this tool versus alternatives such as taiga_wiki_get_by_slug. The phrase 'by ID' gives only implied context, not a clear directive.
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, the description must disclose behavioral traits, but it only restates the operation and resource. It does not mention whether deletion is permanent, what side effects occur, or any authorization requirements.
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 no wasted words. It is front-loaded and immediately communicates the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so this is minimally adequate. However, it lacks useful context about how to obtain the wiki link ID, whether deletion is irreversible, and how this operation differs from deleting a wiki page.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter 'id' as 'Wiki link ID', so the description does not need to add more. The description adds no extra semantic meaning, but the schema coverage is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('a wiki link'), making the purpose unambiguous. It also differentiates from siblings such as taiga_wiki_delete by targeting wiki links rather than wiki pages.
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. There is no mention of when to use this tool, any prerequisites, or how it compares to alternatives like taiga_wiki_links_update or taiga_wiki_delete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that the tool lists watchers, without disclosing the return format, whether it's a read-only operation (though implied), or any other behavioral traits. The agent gets no insight into what the response contains.
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 no filler, front-loading the action and resource. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, and the description gives the core purpose. However, without annotations or return-value details, the agent is left guessing about the response structure and any special behavior. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the only parameter 'id' as 'Wiki page ID' with 100% coverage. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
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 'List watchers of a wiki page' uses a specific verb ('List') and a clear resource ('watchers of a wiki page'). It distinguishes itself from sibling tools like taiga_wiki_get or other *_watchers tools by specifying 'wiki page'.
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 explicit guidance on when to use this tool versus alternatives. The description does not mention that wiki pages have distinct watcher tools or provide any exclusions or prerequisites. Usage is only implied by the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'Get' implies a safe read operation, but the description does not explicitly state that the tool has no side effects, nor does it mention error behavior or return characteristics. It is minimally adequate but lacks explicit transparency about permissions, idempotency, or failure modes.
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: 'Get an epic by ID.' It is front-loaded, contains zero waste, and every word earns its place. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool with one parameter and no output schema, the description is largely complete. It tells the agent what resource is retrieved and how it is identified. However, it does not mention the response structure or any edge-case behavior, though for a standard fetch operation this is generally implied. The absence of an output schema means a little more detail could be justified, but given the tool's simplicity, the current description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single parameter 'id' with a description 'Epic ID'. The description's mention of 'by ID' aligns with the schema but adds no additional semantic value beyond what is already in the input schema. The baseline of 3 applies because 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 clearly states the verb 'Get' and the resource 'epic', and specifies the lookup method 'by ID'. However, it does not distinguish itself from the sibling tool taiga_epics_get_by_ref, which also fetches an epic but by a different identifier. The name and param make the distinction clear, but the description itself does not mention 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?
The description provides no guidance on when to use this tool versus alternatives like taiga_epics_get_by_ref or taiga_epics_list. It lacks any context about use cases, prerequisites, or exclusions, leaving the agent without explicit selection criteria.
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. While 'Get' implies a read-only operation, it does not mention any potential error conditions, authentication requirements, or whether the full issue object is returned. The description adds minimal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence ('Get an issue by ID') with no wasted words. It is appropriately sized for a simple get-by-ID operation and is front-loaded with the primary action.
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?
Given the low complexity (one parameter, no output schema), the description is nearly complete for selecting the tool. However, it lacks any indication of when to use this tool over the similarly name taiga_issues_get_by_ref, which prevents a perfect completeness score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the only parameter (id) with a clear description 'Issue ID', meeting the high schema_description_coverage criterion. The description adds no new semantic information about the parameter beyond what is already in the schema.
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 'Get an issue by ID' clearly states a specific verb (Get) and resource (issue) with an identifier, distinguishing it from siblings like taiga_issues_list and taiga_issues_get_by_ref by specifying the retrieval method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that taiga_issues_get_by_ref should be used when a numeric ref is available, nor does it state that taiga_issues_list is for listing. The usage context is implied only by the tool name and ID parameter.
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, and the description only says 'Bulk invite members to a project.' It does not disclose whether this is a write operation, what permissions are required, whether existing memberships are affected, or what happens on partial failure. The description carries the full burden and falls short.
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, clear sentence with no redundant words. It is concise and front-loaded, effectively communicating the core purpose without unnecessary 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?
Despite having complete schema documentation, the tool lacks annotations and an output schema. The description does not mention return values, permissions, side effects, or error behavior. For a mutation operation, this is insufficient for an agent to fully understand the tool's behavior and invoke it 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?
The input schema already provides full descriptions for both parameters (project_id and bulk_memberships), including the nested role_id and username. The description adds no additional parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Bulk invite') and resource ('members to a project'), making it obvious what the tool does. It also differentiates from the singular taiga_memberships_create tool by emphasizing 'bulk'.
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 word 'bulk' implies it should be used for multiple memberships, but there is no explicit guidance on when to use this vs. taiga_memberships_create or other alternatives. It lacks specific when-to-use/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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Get'. It does not specify the return format, potential errors, side effects, or that the operation is read-only. This is insufficient for a tool with no annotation support.
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, direct sentence that fully conveys the action and object. It is appropriately sized for the tool's simplicity, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description is mostly complete. However, it does not mention what the response looks like (e.g., a map of attribute IDs to values) or what happens if no custom attributes exist, which would be useful given the lack of an output schema.
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 provides 100% coverage for the sole parameter 'id' with the description 'task ID'. The tool description adds no additional meaning beyond the schema, so it does not enhance parameter understanding. The baseline applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves custom attribute values for a task, specifying both the resource (task) and the data type (custom attribute values). It distinguishes from sibling tools like taiga_task_custom_attributes_get, which likely retrieves attribute definitions, by explicitly using 'values'.
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 compared to alternatives, such as when to prefer it over taiga_task_custom_attributes_get or when not to use it. There are no prerequisites, exclusions, or alternative recommendations provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavioral traits. It only states the action ('bulk update') without mentioning side effects, required permissions, whether the operation replaces existing order or merges, or any error conditions. This is a significant gap for a mutating operation.
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 ('Bulk update kanban order of user stories.') that front-loads the key information with no filler. Every word adds 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?
Although the tool is relatively simple, the description is too terse to be fully complete. It does not explain what 'kanban order' means in this context (e.g., absolute vs. relative ordering, ordering within columns), what the response format looks like, or any prerequisites. With no annotations and no output schema, this leaves the agent without enough information to invoke the tool confidently.
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%: project_id is labeled 'Project ID' and bulk_stories is described as 'Array of [us_id, order] pairs', which already conveys the structure and meaning. The description adds no additional parameter details, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('bulk update'), names the resource ('user stories'), and identifies the exact scope ('kanban order'), distinguishing it from sibling tools that update backlog or sprint order. It is unambiguous about what operation is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when bulk reordering user stories in the kanban board) but provides no explicit guidance on when not to use it or how it differs from the closely related bulk_update_backlog_order and bulk_update_sprint_order tools. The context is clear but no 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 present, so the description must carry the full burden of behavioral disclosure. It only restates the operation name without disclosing authentication requirements, idempotency, error behavior when no vote exists, or whether it affects the current user's vote.
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, immediately front-loaded, with no filler or redundancy. It earns its place entirely.
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 mutation with no output schema or annotations, the description provides minimal but functional guidance. It lacks context about authentication, return values, or when this action is valid, but the simple operation may not require more for basic invocation.
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%: the single required 'id' parameter includes a description ('Epic ID'). The tool description adds no extra parameter meaning, but the schema fully documents it, so baseline 3 applies.
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 'Remove vote from an epic.' uses a specific verb ('remove') and resource (epic), clearly distinguishing it from sibling tools like taiga_epics_upvote or taiga_epics_voters. It directly states the action without ambiguity.
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?
No explicit when-to-use or alternative guidance is provided; the description only states the action. Usage is implied from the verb, but there is no mention of prerequisites or how it contrasts with taiga_epics_upvote.
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 only states that it gets an epic, with no information about read-only nature, authentication requirements, error behavior, or return format. The description adds minimal context beyond the basic operation.
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, front-loaded with the key information. It contains no fluff or redundancy, making it appropriately concise for a simple getter 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 get tool with no output schema, the description provides the essential purpose but lacks context about return values, potential errors, or differences from similar tools. It is minimally viable but leaves gaps in a complete understanding of the tool's behavior.
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 'ref' and 'project' documented in the schema. The description repeats these parameter names but adds no additional meaning, such as format, constraints, or relationships. Baseline 3 is appropriate because the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with resource 'epic' and qualifiers 'by ref and project', clearly distinguishing it from sibling tools like taiga_epics_get (which likely retrieves by ID) and taiga_epics_list. The purpose is unambiguous and specific.
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 when a ref and project are known, but it does not explicitly state when to use this versus alternatives such as taiga_epics_get or taiga_epics_list. There is no mention of exclusions or alternative tools, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only restates the tool's name ('List voters of an epic') without adding any behavioral context such as authentication requirements, response shape (e.g., list of user objects), pagination, or whether it is a read-only operation (though 'list' implies read). It adds nothing beyond the 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?
The description is a single, concise sentence that is front-loaded with the verb and target. Every word is necessary, and there is no unnecessary elaboration.
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 list operation with one fully documented parameter, the description is minimally viable. However, there is no output schema, so the agent does not know the return format (e.g., array of user objects). It also lacks any contextual notes about when the list might be empty or how voting works, making it slightly below complete for a seamless agent interaction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a description ('Epic ID') for the only required parameter 'id'. The description does not add any additional meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the target resource ('voters of an epic'), which is specific and unambiguous. It distinguishes from sibling tools that deal with watchers, upvotes, or voters of other entities (e.g., taiga_userstories_voters, taiga_epics_watchers).
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: call this tool when you need to see who voted for a specific epic. However, it provides no explicit guidance on when not to use it or alternatives (e.g., taiga_epics_upvote/downvote for modifying votes, or taiga_epics_watchers for watchers). It is adequate but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly implies a read-only operation via 'List', but it does not disclose details such as authentication requirements, return format, or pagination. The simple verb 'list' makes the core behavior clear, but richer context is absent.
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 no unnecessary words. It front-loads the key information and avoids extraneous detail, making it highly concise for such a simple 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?
The low complexity (1 required parameter, no output schema) makes a brief description somewhat acceptable, but the lack of any mention of the return format or how watchers are represented is a gap. Without an output schema, the description could have clarified what the response contains, and it does not situate the tool relative to the many similar watchers 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?
The schema has 100% coverage with the parameter 'id' described as 'Epic ID'. The description adds no additional meaning beyond the schema. Given the high 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List watchers of an epic' clearly states the action (list) and the target resource (watchers of an epic). It is specific enough to distinguish from sibling tools like taiga_epics_voters or taiga_epics_watch, as it explicitly focuses on watchers of an epic.
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 taiga_epics_voters, taiga_epics_watch, or watchers tools for other entities. There are no context cues, prerequisites, or exclusionary statements, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only restates the tool's purpose without mentioning read-only status, response format, error behavior, or any side effects. This is insufficient for an MCP tool, though the get operation is inherently low-risk.
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 is front-loaded with the verb and object, with zero redundancy and no wasted words. It is appropriately concise for a simple getter 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?
The tool is simple (one required parameter), but with no output schema and no description of the return value, the agent is left guessing about what the response contains. The description is adequate for basic usage but misses important context like value structure and potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameter descriptions (id is described as 'issue ID'), so the description adds no additional parameter value. Baseline 3 applies since schema does the heavy lifting and the description doesn't conflict or add nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Get'), the resource ('custom attribute values'), and the scope ('specific issue'). It distinguishes this from sibling tools that handle custom attributes for epics, user stories, or tasks, and from tools that manage custom attribute definitions rather than values.
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?
Usage context is implied by the resource and tool name, but there is no explicit guidance on when to use this tool versus related tools, such as taiga_issue_custom_attributes_get (for definitions) or taiga_issue_custom_attributes_values_update (for updates). No exclusions or alternative recommendations 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 behavioral disclosure burden. It only states 'Get an issue', which is a read operation, but it does not describe what data is returned, whether it fails for invalid refs, or any authentication requirements. The description adds minimal behavioral context beyond the obvious.
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 an eight-word sentence that immediately conveys the operation and its key scope. There is no filler, redundant phrasing, or unnecessary detail, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with two well-specified parameters, the description is adequate but not complete. It does not describe the return value (e.g., 'returns the full issue object') or any failure behavior, and there is no output schema to compensate. However, the operation is straightforward, so a minimal description is somewhat acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for both parameters: 'Issue ref number' for ref and 'Project ID' for project. The description 'by ref and project' reinforces that these are lookup keys but adds no new meaning beyond the schema. With 100% 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get an issue by ref and project' clearly states the verb (get), the resource (issue), and the key identifiers (ref and project). This distinguishes it from taiga_issues_get, which presumably fetches by internal ID, and from list/create/update/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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage is appropriate when you have an issue's ref and project ID, but it does not explicitly contrast with alternatives like taiga_issues_get (which likely uses the issue ID). No exclusions or 'when not to use' guidance is provided, leaving the agent to infer the distinction from 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, reversibility, permission requirements, or the fact that it's a mutating operation. This is a minimal gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, four-word sentence that is front-loaded and contains no waste. Every word earns its place for the simple action.
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 simple one-parameter schema and no output schema, the description conveys the core function but lacks context about behavior, return values, or usage conditions. It is minimally viable but not richly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'id' parameter, which is described as 'Issue ID'. The description adds no additional meaning beyond the schema, so it sits at the baseline.
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 'Stop watching an issue' clearly states the action (stop watching) and the resource (an issue). It is specific and distinguishes this tool from sibling unwatch tools by limiting to issues.
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 when the user wants to stop watching an issue, but does not provide explicit guidance on when to use this tool versus alternatives like taiga_projects_unwatch or taiga_tasks_unwatch. The context is clear but no exclusions or alternative tools 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 the full burden. It discloses only the core listing behavior and filter options, without mentioning pagination, default scope (all memberships vs. scoped), authentication requirements, or response format. This adds little beyond what the name and schema already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, directly to the point, with no verbosity. 'List memberships' states the action, and 'Filter by project or role' adds useful filter capability. Every word earns its place.
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 list tool with two optional filters, the description is minimally adequate, but it omits default behavior when no filters are given and any return-value or pagination details. Since there is no output schema, the description should compensate more for these missing behavioral cues.
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 both parameters already described as 'Role ID' and 'Project ID'. The description only restates that filtering by project or role is possible, adding no new semantics about how the filters interact (e.g., AND/OR) or value formats. Baseline 3 is appropriate when the schema handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('memberships'), and mentions filtering capabilities. This distinguishes it from sibling tools like taiga_memberships_get, create, update, and delete, which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to list memberships with optional filters by project or role, but it does not explicitly contrast it with similar endpoints such as taiga_memberships_get for retrieving a single membership, nor does it mention when not to use this tool. Usage guidance is embedded in the action name but not elaborated.
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 is the sole source of behavioral information. It indicates a read-only 'Get' operation and that it returns stats, but does not disclose whether specific permissions are needed, the exact response structure, or any side effects. The additional context beyond the name is minimal (the 'burndown' example).
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 no filler or repetition. 'Get milestone/sprint stats (burndown, etc.)' conveys the core purpose efficiently. The use of 'etc.' is slightly vague but does not detract from 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?
Given the simple one-parameter tool and the lack of an output schema, the description would need to explain what stats are returned to be fully complete. It only offers the vague example 'burndown, etc.', which may leave an agent unsure about the exact return data. The read-only nature is implied but not explicitly stated, though 'Get' helps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (id) with a clear description 'Milestone ID', and the schema description coverage is 100%. The tool description does not add any parameter-related information, but the baseline for high schema coverage is sufficient. Thus it neither helps nor hurts.
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 tool retrieves stats for a milestone/sprint, with 'burndown' as an example. This distinguishes it from sibling tools like taiga_milestones_get, which fetches the milestone itself. However, 'etc.' leaves some ambiguity about the full scope of stats.
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 tool is for obtaining sprint statistics but does not explicitly state when to prefer it over similar tools like taiga_milestones_get or taiga_projects_stats. There are no exclusions or alternative references. Usage context is only implied by the word 'stats' and the example 'burndown'.
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 states the deletion action without mentioning side effects, permissions, irreversibility, or error behavior, leaving significant gaps for a mutating operation.
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, 'Delete a tag from a project,' with no wasted words. It is front-loaded with the verb and resource, achieving maximum 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?
The tool is simple with two well-described parameters and no output schema. The description covers the core purpose but lacks any detail about response behavior or edge cases. Given the low complexity, it is minimally 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?
The schema fully covers both parameters with clear descriptions ('Project ID' and 'Tag name'), so schema coverage is 100%. The description adds no additional meaning beyond the schema, aligning with the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' and identifies the resource as 'a tag from a project.' This clearly distinguishes it from sibling tools like create_tag, edit_tag, and project delete.
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 does not explicitly state when to use this tool versus alternatives, such as create_tag or edit_tag. The action is obvious from the name and verb, but no explicit guidance on alternatives or exclusions is provided, relying on implied usage.
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. It states the core action (resolve slug to ID) but does not disclose whether the operation is read-only, requires authentication, or what happens when the slug is not found. The word 'resolve' implies a lookup, but side effects and error behavior remain unspecified.
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 no superfluous words. It is front-loaded with the action and directly states the tool's purpose, making it easy to scan.
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 (two params, no output schema, no annotations), and the description conveys the fundamental purpose. However, it lacks details such as what happens when the slug is not found, whether the operation is read-only, and how the project parameter scopes the lookup. These gaps could confuse an agent in edge cases, but the basic functionality is clear.
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?
Both parameters have descriptions in the schema ('Wiki page slug' and 'Project slug'), so schema coverage is 100%. The description adds no additional meaning beyond the schema and does not explain how the two parameters interact (e.g., that the wiki slug is scoped to the project). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Resolve' and clearly identifies the resource (wiki page slug) and the outcome (its ID). It distinguishes this tool from sibling resolver tools by specifying 'wiki', making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when you have a wiki slug and need the corresponding ID, but it does not explicitly mention when to use this instead of alternatives like taiga_wiki_get_by_slug. There is no explicit context about the project parameter's role 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Global search' without detailing what fields are searched, whether results are categorized by type, or if any pagination exists. This is a notable gap for a search tool, as the return format and search semantics are unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately communicates the tool's core purpose and scope. There is no redundant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two well-described parameters) and lack of output schema, the description captures the essential scope (project and text) but omits any explanation of the return value or search behavior. It is minimally viable but leaves gaps about what the agent can expect as a result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters ('Search text' and 'Project ID'), achieving 100% schema coverage. The tool description adds no additional meaning to the parameters, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Global search across a project' and enumerates the entity types covered (user stories, tasks, issues, wiki pages). This distinguishes it from the many type-specific list tools (e.g., taiga_userstories_list) by emphasizing its cross-entity scope.
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?
Use of the tool is implied: it is for broad searching across multiple entity types within a project. However, the description does not explicitly mention when to prefer this over type-specific list tools or provide exclusions, leaving usage guidance implicit rather than 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?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. The 'partial' qualifier indicates that only supplied fields are modified, which is a valuable behavioral trait. However, it does not disclose permissions, error behavior, side effects, or the response format, leaving significant gaps for a mutation tool. The description is too sparse to be transparent about the tool's behavior beyond the core 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, concise sentence with no filler words. It front-loads the action 'Update' and immediately qualifies it with '(partial)', making it very efficient. Every word earns its place, and there is no unnecessary detail or repetition.
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?
Despite having no annotations and no output schema, the description combined with the input schema provides enough information for a basic invocation: provide an id and optionally other fields. The 'partial' qualifier is crucial for understanding the update behavior. However, it omits details about the response format and any side effects, which might be necessary for full completeness. Given the low complexity of the operation, this earns a moderate score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only 20% description coverage, with only the id parameter given a description. The description's '(partial)' helps clarify that all other parameters are optional and only provided ones are updated, adding semantic value beyond the schema. It does not explain the meaning of each field, but the field names (name, color, order, is_closed) are self-explanatory, and the partial-update context compensates for the low 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 clearly states the action 'Update' and the resource 'severities', making it unambiguous that this is the update operation for severity records. The '(partial)' qualifier adds useful context that it is a partial/PATCH update, distinguishing it from a full replacement or other severity-related tools. Even with the grammatical quirk 'a severities', the purpose is clear, especially considering sibling tools like taiga_severities_create and taiga_severities_delete.
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 does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions. However, as an update operation, its usage is implied: it is the tool to modify an existing severity record, which is evident from the verb and the presence of sibling tools like taiga_severities_create and taiga_severities_delete. No guidance is given for distinguishing it from bulk_update_order, but the implied context is sufficient.
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 burden. It only states 'Get' which implies a read operation, but it discloses no additional behavioral traits such as authentication requirements, error handling, or the contents of the returned definition. This is minimal beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently states the action and resource, making it easy to parse at a glance.
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 getter with no output schema and no annotations, the description conveys the core purpose but lacks context about return format or usage relative to sibling tools. It is minimally viable but leaves gaps that could affect 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?
The input schema fully documents the only parameter 'id' as 'Custom attribute ID' (100% coverage), so the baseline is 3. The description adds no extra meaning to the parameter, simply referring to 'a custom attribute definition' without further elaboration.
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 'Get a custom attribute definition for task' uses a specific verb ('get'), identifies the resource ('custom attribute definition'), and scopes it to 'task'. This clearly distinguishes it from sibling tools like taiga_task_custom_attributes_list and from similar getters for other entity types (e.g., taiga_epic_custom_attributes_get).
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?
No explicit when-to-use guidance is provided. The verb 'get' and the required 'id' parameter imply this is for retrieving a specific definition by ID, but the description does not mention when to choose this over alternatives such as taiga_task_custom_attributes_list or taiga_task_custom_attributes_values_get. Guidance is only implied, not 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states only the action and does not mention prerequisites (e.g., authentication), side effects, idempotency, or what happens if the user has not previously voted. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately concise for the simplicity of the 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?
The tool is simple with one well-documented parameter and no output schema, but the description lacks behavioral details such as auth requirements or error conditions. It is minimally viable but not fully complete for an unannotated 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?
The schema already describes the single parameter 'id' as 'Task ID' with 100% coverage. The description adds no additional meaning about the parameter, so the baseline score of 3 applies.
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 'Remove vote from a task' uses a specific verb ('remove') and resource ('vote', 'task'), clearly distinguishing it from sibling tools like taiga_tasks_upvote. It leaves no doubt about the action performed.
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 usage context is implied by the description: it should be used when wanting to remove a vote from a task. However, there is no explicit comparison to alternatives (e.g., taiga_tasks_upvote) or exclusion scenarios, so it provides only implied 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, and the description is a minimal restatement of the tool's name. It does not disclose whether the operation is read-only, what fields are returned, error behavior, or any prerequisites. This leaves the agent without additional behavioral context beyond the name and parameters.
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 immediately states the action and key identifiers. It earns its place with no fluff, though it is sparse.
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 tool's low complexity and full schema coverage, the description is minimally viable, but it lacks behavioral disclaimers and output information. Since no annotations or output schema exist, the bare-bones description leaves some gaps for an AI agent to make assumptions about the returned payload.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for both ref ('Task ref number') and project ('Project ID'). The description adds no extra meaning—only re-mentions that both are needed. Baseline 3 applies because the schema fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with the resource 'task' and identifies the lookup keys 'ref and project'. This clearly differentiates from sibling tools like taiga_tasks_get or taiga_issues_get_by_ref, as it specifies both the resource and the unique identifier pattern.
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 when you have a task ref and project ID, but it does not explicitly contrast with taiga_tasks_get (likely by ID) or any other alternative. No 'when-not' guidance is provided, so the agent must infer usage from the schema and name.
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 states the operation ('List') without mentioning authentication needs, response format, pagination, or behavior for nonexistent task IDs. The read-only nature is implied but not explicit.
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, five-word sentence with zero wasted words. It is fully front-loaded and every word earns its place, making it an exemplary concise description for a simple 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 one-parameter list tool, the description is minimally adequate and matches the tool's simplicity. However, with no output schema and no annotations, it fails to clarify the return shape (e.g., list of user objects) or any error conditions, leaving clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the only parameter 'id' is already described as 'Task ID' in the schema. The description adds no additional meaning to the parameter, so it stays at the baseline for complete 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 uses a specific verb ('List') and resource ('watchers of a task'), clearly defining the operation. It distinguishes well from sibling tools like taiga_tasks_voters, taiga_tasks_watch/unwatch, and watcher tools for other entity types (projects, epics, issues, etc.).
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 intended use case (retrieve the watcher list for a given task) is implied by the description, but there is no explicit guidance on when to use this tool versus alternatives. It does not mention related tools such as taiga_tasks_watch/unwatch or clarify 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, and the description only says 'List attachments of a user story,' offering no information about read-only status, pagination, response format, or required permissions. This leaves the behavioral burden entirely on the agent, which 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, front-loading the essential purpose. It is appropriately sized for a simple list 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?
While the tool is straightforward, the description omits any indication of what the response contains (e.g., attachment metadata) or how the project parameter relates. With no output schema, this minimal text meets the minimum viable threshold but lacks additional context to fully guide the agent.
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?
Both parameters are fully described in the schema (Project ID, User Story ID), so the description adds no semantic value beyond what the schema already provides. The baseline of 3 applies due to high 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 clearly states the action (list) and the resource (attachments of a user story). The 'user story' scope distinguishes it from sibling attachment list tools for epics, tasks, issues, and wiki.
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 provides no explicit guidance on when to use this tool versus alternatives like taiga_userstories_attachment_get or other attachment list tools. Usage is implied from the resource name but not explicitly 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?
With no annotations, the description must disclose behavioral traits, but it only states the action. It does not mention permissions, atomicity, return values, or what happens to existing order, which is a significant gap for a bulk mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero waste, front-loading the key verb and resource. It is appropriately 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?
The description is minimal but the schema is complete. However, for a bulk order update, it does not clarify whether the pairs replace all orders or partially update, nor any prerequisites. The simplicity of the tool keeps this at a 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?
The input schema provides 100% coverage with descriptions for both parameters (project_id and bulk_stories). The description adds no meaning beyond the schema, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('bulk update') and the resource ('backlog order of user stories'), distinguishing it from sibling tools like bulk_update_sprint_order or bulk_update_kanban_order.
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?
No explicit guidance is provided on when to use this tool vs alternatives. The context is implied by the name and the mention of 'backlog', but there is no explicit exclusion or alternative recommendation.
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, the description carries the full burden of behavioral disclosure. It confirms a read-only list operation but does not mention authentication requirements, output format, or error behavior.
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 consists of a single, efficient sentence that conveys the tool's purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, and the description adequately identifies the action but does not clarify what is returned (e.g., list of user names) or any edge-case behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter 'id' as 'User Story ID' with 100% coverage, and the description adds minimal value beyond restating that the voters belong to a user story.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('voters of a user story'), clearly distinguishing it from sibling tools like taiga_epics_voters or taiga_tasks_voters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when needing voters for a specific user story, but does not explicitly state alternatives or conditions, such as when to use this over taiga_userstories_watchers or other voter-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey the tool's side effects. It clearly states it creates a definition, which implies a mutating operation, but adds no detail about permissions, duplicate name behavior, or whether the creation is project-scoped beyond the schema's 'project' parameter. For a simple create tool, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that puts the action verb first. Every word contributes to identifying the operation and resource, with no filler or unnecessary 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?
The tool has five parameters, no annotations, and no output schema. The description does not explain what the API returns upon successful creation, nor does it mention validation rules or error conditions (e.g., duplicate names, required permissions). This leaves the agent without a full picture of the tool's behavior.
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', 'type', and 'project' have descriptions, but 'order' and 'description' do not. The tool description does not add any parameter semantics or compensate for the missing descriptions, leaving the agent without guidance on what 'order' means or how 'description' is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and identifies the exact resource ('custom attribute definition for userstory'). This clearly distinguishes it from sibling tools like taiga_userstory_custom_attributes_list, get, update, and delete, leaving no ambiguity about the 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 the tool is used for creating custom attribute definitions for user stories, but it does not explicitly state when to use it versus alternatives such as the update or list tools. No exclusions or alternative references are provided, so usage context is only hinted at by the resource name.
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 merely says 'List attachments' without noting read-only nature, permissions, pagination, or return format. This provides minimal transparency beyond the surface 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, direct sentence with no extraneous words. It is appropriately sized and front-loaded, making it highly 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?
The tool is simple and the input schema is complete, but the description is minimal and does not explain the return structure (e.g., fields in attachment list, ordering, pagination). Since there is no output schema, more context would be helpful, though the description is adequate for a basic list 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?
The schema already fully describes both parameters (project as Project ID, object_id as Wiki page ID), achieving 100% coverage. The description adds no extra parameter context, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') and resource ('attachments of a wiki page'), distinguishing it from sibling attachment tools for epics, userstories, tasks, and issues. The verb+resource structure 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?
The description implicitly suggests when to use this tool by specifying 'wiki page,' which differentiates it from other attachment list tools. However, there are no explicit references to alternatives or exclusionary conditions, so guidance is only implied.
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. The only behavioral disclosure is 'Comment is posted via the history endpoint,' which hints at the persistence mechanism but does not state permissions, side effects, or what happens on success/failure. This is insufficient for a mutating operation without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences with no wasted words. It states the primary purpose first and adds a useful implementation detail in the second sentence, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with two fully documented parameters and no output schema. However, as a mutating tool with no annotations, the description should compensate for missing safety/behavioral information. The history endpoint note provides some context, but the description omits side effects, permissions, and return behavior, leaving gaps in contextual 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?
The input schema already provides full descriptions for both parameters (id = wiki ID, comment = Comment text) with 100% coverage, so the description adds little beyond that. The reference to the history endpoint does not clarify parameter syntax or constraints, leaving the schema to do the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add a comment to a wiki' – a specific verb and resource. The additional note about posting via the history endpoint further distinguishes this tool from sibling comment tools for other entities (e.g., userstory, task) and from the wiki comment deletion tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when a comment needs to be added to a wiki) but provides no explicit guidance on when to prefer it over alternatives or any exclusions. There is no mention of prerequisites or conflicts with sibling tools like taiga_wiki_comment_delete.
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 only says 'Get' implying a read, but does not explicitly state that it is read-only, what it returns, error behavior (e.g., 404 if not found), or authentication needs. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the essential purpose without any fluff. Every word earns its place, and the structure is front-loaded with the verb and resource.
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 get-by-ID tool with one parameter, the description is minimally adequate. However, there is no output schema, so a note about the return value (e.g., the full wiki link object) would improve completeness. The lack of any usage context or behavioral details leaves clear gaps, but the tool is simple enough that selection and invocation are still feasible.
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 'id' parameter is described as 'Wiki link ID'). The description adds no additional meaning beyond restating 'by ID', so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get), the resource (wiki link), and the identifier criterion (by ID). It distinguishes from the sibling taiga_wiki_links_list, which implies a list operation, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you have a specific wiki link ID. However, it does not explicitly state when not to use it or mention alternatives like taiga_wiki_links_list for browsing all links, missing an opportunity for clear 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'List wiki pages' but does not mention return format, pagination, permissions, or any side effects. Since 'list' implies a read operation, this is inferred rather than explicitly disclosed, leaving a gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: 'List wiki pages. Filter by project.' Both are front-loaded, direct, and contain no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with one optional parameter and no output schema. The description explains the core function and filter, but does not describe what the response contains (e.g., an array of wiki pages). Since no output schema exists, some return-value information would strengthen completeness, making this minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single optional 'project' parameter described as 'Project ID'. The description adds 'Filter by project', which reinforces the parameter's role but provides no additional syntax or format details. Baseline of 3 is appropriate given complete 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 clearly states the verb 'List' and resource 'wiki pages', and mentions the optional filter by project. This distinguishes it from sibling tools like taiga_wiki_get (single page retrieval) and taiga_wiki_links_list, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing wiki pages with optional project filtering, but it does not explicitly state when to prefer this over alternatives such as taiga_wiki_get or taiga_wiki_history, nor does it provide exclusions or prerequisites. The guidance is minimal but not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. The 'Get' verb clearly indicates a read-only operation, but no additional context is given about error handling, permissions, or response format. It is minimal but not misleading for a simple retrieval operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. It earns its place by clearly stating the tool's purpose without any filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET operation with one parameter and no output schema, the description is sufficient. It conveys the core action and resource, and the parameter is well-documented in the schema. A brief note about the response being the full definition could add value, but it's not essential for this straightforward 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?
The input schema provides 100% description coverage for the single 'id' parameter ('Custom attribute ID'), so the schema already fully documents the parameter. The description adds no extra semantic detail beyond what the schema states, aligning with the baseline score for high 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 clearly states the action ('Get') and the resource ('custom attribute definition for epic'). It distinguishes this tool from siblings like taiga_epic_custom_attributes_list (which lists all) and taiga_epic_custom_attributes_values_get (which retrieves values), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 when to prefer this over the list or values getter, nor any exclusions or prerequisites. The description is purely functional and lacks contextual usage 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?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It states what the tool does (gets values) but does not disclose whether it returns values for all custom attributes, how missing values are handled, or any response structure. This is a simple read operation, but the description adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is immediately clear and front-loaded with the key verb and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool with no output schema, the description is mostly complete. It clearly states the purpose and the parameter is fully documented, though it could have mentioned what the returned values look like. Overall, sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the sole parameter 'id' as 'epic ID' (100% coverage). The description reinforces this by saying 'for a specific epic' but adds no additional syntax or format details beyond what the schema provides.
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 states a specific verb ('Get') and resource ('custom attribute values for a specific epic'), clearly distinguishing it from sibling tools like taiga_epic_custom_attributes_get (which gets attribute definitions) and taiga_epic_custom_attributes_values_update (which updates values).
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 in that it requires an epic ID, but it does not explicitly state when to use this tool versus alternatives like taiga_epic_custom_attributes_list or taiga_epic_custom_attributes_get. No exclusions or alternative tool names 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?
With no annotations provided, the description carries the full burden. It clarifies that this returns definitions rather than values, but does not disclose behaviors like whether the project filter is optional, pagination, authentication requirements, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource, with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one well-documented optional parameter and no output schema, the description is adequately complete. It states the primary function and the only filter, though it could mention that project is optional or describe what 'definitions' include.
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 the project parameter is fully described in the schema. The description adds the notion of 'Filter by project', which implies optionality and purpose, but does not add significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource as 'custom attribute definitions for issue', clearly distinguishing it from sibling tools like taiga_epic_custom_attributes_list and taiga_issue_custom_attributes_values_get.
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?
It implies usage for listing issue custom attribute definitions and notes optional filtering by project, but does not explicitly state when to use this tool over alternatives, such as when to use taiga_issue_custom_attributes_values_get for values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It conveys a read-only listing operation, but does not add details about the return format, pagination, or authentication requirements. For a simple read operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with zero wasted words. It is immediately clear and front-loaded.
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?
Given the tool's simplicity (one parameter, no output schema), the description is mostly sufficient. It could mention the return value (e.g., list of user objects) but is not severely lacking for a straightforward read-only list 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?
The schema fully documents the single parameter 'id' as the Milestone ID. The description adds no additional parameter meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('watchers of a milestone'). It effectively distinguishes this tool from sibling watcher tools for other entities by specifying the milestone resource.
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. The description does not mention that this is the appropriate tool for milestone watchers, nor does it reference other watcher tools for other entities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the transparency burden. It discloses a read operation ('List') and the filtering capability, but it omits details like pagination, ordering, or behavior when no filter is provided. It's adequate for a simple list tool but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, with two short sentences that are front-loaded and contain no redundant information. It earns its place without wasting words.
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 (one optional parameter), but the description doesn't clarify what the response looks like nor whether the project is required or optional. Without an output schema, some return-value context would be helpful. It is sufficient for basic selection and invocation but leaves gaps.
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% for the single 'project' parameter, and the description adds semantic meaning by stating it serves as a filter, which goes beyond the schema's 'Project ID' label. This clarifies the parameter's role.
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 'List points. Filter by project.' clearly states a verb and resource. It distinguishes this from other list tools by specifying the resource 'points,' though it doesn't define what 'points' means in the Taiga context.
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 phrase 'Filter by project' implies a usage context (listing points with optional project filtering), but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions 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?
The description lacks details about side effects (though a resolver implies no mutation), error behavior for invalid refs, or the exact return format (just 'its ID'). With no annotations provided, the description carries the full burden but offers only the core transformation without additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter resolver, the description sufficiently explains the operation and output. While it could mention error cases, the tool's low complexity and fully described parameters make it complete enough.
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?
Both parameters are fully documented in the schema with descriptions ('Issue ref number' and 'Project slug'), so the description adds no extra meaning beyond what the schema already provides. This aligns with the baseline of 3 due to high 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 clearly states the action ('Resolve') and the resource ('an issue ref') and the result ('to its ID'). This distinguishes it from sibling resolver_* tools (project, userstory, task, etc.) by specifying 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The verb 'Resolve' and the existence of sibling resolver tools imply it is used to translate an issue ref into an internal ID, but this is only implied, not directly 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. It states the action ('Resolve...to its ID') but does not disclose behavioral nuances such as whether this is a read-only operation, what happens if the slug is not found, or that the project parameter is required for disambiguation. The one-sentence description adds no context beyond the core purpose.
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 one short sentence with no redundant words. It delivers the essential information front-loaded and nothing more, which is ideal for a simple resolver 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?
For a low-complexity lookup tool with 100% parameter schema coverage, the description is largely complete: it states the purpose and output. It does not describe error behavior or explain the need for the project parameter beyond the schema, but this is a minor gap given the tool's simplicity and the schema's clarity.
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 'project' and 'milestone' have descriptions ('Project slug' and 'Milestone slug'). The main description adds no additional meaning beyond the schema, and the parameter names are self-explanatory. Therefore the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resolve a milestone slug to its ID' uses a specific verb ('Resolve') and names the exact resource (milestone) and outcome (ID). It clearly distinguishes itself from sibling resolver tools by explicitly mentioning milestone, and from milestone CRUD tools by stating its resolution purpose.
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 usage scenario: when you have a milestone slug and need its ID. However, it does not explicitly state when to use this tool over alternatives like taiga_milestones_get or mention any exclusions/prerequisites. The guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It states the core behavior (slug to ID) but does not disclose what happens for invalid slugs, whether it returns only the ID or a larger object, or any authentication requirements. This is acceptable for a simple resolver but leaves some behavioral aspects unexplained.
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 includes both the action and the input/output relationship. It contains zero redundant words and is perfectly sized for the tool's simple functionality.
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?
Given the tool's low complexity (one parameter, no output schema, no nested objects), the description adequately covers what the tool does and what it returns (an ID). It could mention error behavior, but the core transformation is clearly specified, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for the sole parameter ('Project slug') with 100% coverage. The description adds no additional semantic information beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Resolve') and the resource ('a project slug to its ID'), making the tool's purpose unambiguous. It distinguishes from other resolvers by specifying 'project' and the output as an ID, though it doesn't explicitly contrast with the similar-sounding taiga_projects_get_by_slug.
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 usage context is implied by the name and description: use this tool when you have a project slug and need its numeric ID. However, there is no explicit guidance on when to choose this over alternatives like taiga_projects_get_by_slug, or any mention of prerequisites or fallbacks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the core action ('resolve') and the output ('ID'), which implies a read-only lookup, but it does not explicitly confirm the absence of side effects, authentication requirements, or error behavior. The description adds some value but leaves gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of nine words, directly front-loaded with the verb 'Resolve.' It contains zero redundancy and efficiently conveys the entire purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple resolver tool with two well-documented parameters and no output schema, the description sufficiently explains the return value ('to its ID'). It does not elaborate on error cases or prerequisites, but the combination of description and schema covers the essential information needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with descriptions ('Project slug' and 'User story ref number'), achieving 100% schema coverage. The description does not add meaningful semantic detail about the parameters beyond what is in the schema; it merely restates that the user story ref is resolved. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Resolve a user story ref to its ID.' It specifies a specific verb ('resolve'), a resource ('user story ref'), and the expected outcome ('to its ID'). This distinguishes it from other resolver tools (e.g., taiga_resolver_task, taiga_resolver_epic) by explicitly naming 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?
The description provides no guidance on when to use this tool versus alternatives such as taiga_userstories_get_by_ref, nor any prerequisites or exclusions. The only usage hint is implied by the function's name and purpose, but no explicit context 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, so the description carries the full burden of behavioral disclosure. It only states 'Get a role by ID' — a read operation — but does not disclose what happens if the role is not found, whether authentication is required, what the return structure looks like, or any error behavior. This is minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded with the action and directly states the resource and qualifier, achieving maximum clarity per word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the essential purpose and parameter. It could be more complete by mentioning the return type or error cases, but for a basic get-by-ID operation, it is adequate. The lack of annotations is partly compensated by the simplicity 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?
The input schema has 100% coverage with the parameter 'id' described as 'Role ID'. The tool description adds no additional meaning beyond 'by ID', so the schema does the heavy lifting. With high schema coverage, the baseline score of 3 applies.
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 'Get a role by ID' uses a specific verb ('Get'), identifies the resource ('role'), and specifies the scope ('by ID'). This clearly distinguishes it from sibling tools like taiga_roles_list, taiga_roles_update, and taiga_roles_delete.
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?
Usage is implied: the tool is used when you have a role ID and want to fetch the role. However, there is no explicit guidance on when to use this tool versus alternatives, nor any exclusion conditions. A simple getter like this gains context from its name, but the description offers no added 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 present, so the description carries the full burden of disclosing behavioral traits. It only states 'update' without clarifying critical details like merge vs. replace semantics, behavior on version conflicts, required permissions, or the return format. This is a significant gap for a mutation tool with a version parameter.
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 no filler, front-loading the action and resource. It earns its place with maximum efficiency.
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?
Despite full schema coverage, the description omits key operational context: the version parameter's role in conflict checking is only in the schema, and there is no explanation of partial vs. full replacement or response behavior. With no annotations or output schema, these gaps remain unfilled.
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% — all three parameters have descriptions. The description adds no extra parameter meaning beyond restating that custom attribute values are being updated, which is sufficient given the schema already documents each parameter.
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 'Update custom attribute values for a specific task' uses a specific verb ('Update'), names the resource ('custom attribute values'), and narrows scope ('specific task'). This clearly differentiates it from sibling tools for epics, user stories, and issues, as well as from taiga_task_custom_attributes_update which updates attribute definitions rather than values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this tool is task-specific, which implicitly tells the agent to use it when updating custom attribute values on a task. However, it does not explicitly mention when not to use it or name alternatives (e.g., epic/userstory/issue variants), so it lacks the explicit exclusions needed for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. 'Get' implies a read-only operation, adding basic safety context, but it omits details about error handling, authentication requirements, or response format. The minimal read-only implication justifies a mid-tier score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It is appropriately sized for a simple 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?
For a basic get-by-ID operation with full schema coverage and no output schema, the description is largely complete. However, it does not explicitly describe the return value, though this is arguably implicit for a 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?
The schema fully describes the single 'id' parameter with 100% coverage ('Task ID'), so the description does not need to add parameter semantics. It adds no information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'task' and identifier 'ID', making it clear this is a fetch operation. It distinguishes from sibling tools like taiga_tasks_list (list) and taiga_tasks_get_by_ref (by ref) through the explicit use of '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?
The description provides no guidance on when to use this vs. alternatives such as taiga_tasks_get_by_ref or taiga_tasks_list. It simply states the action without contextual exclusions or alternative recommendations.
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 discloses no behavioral details beyond the basic action, such as pagination, ordering, authentication requirements, or response format. There is no contradiction, but also no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence: 'List projects liked by a user.' It is front-loaded with the verb and resource, contains no filler, and is appropriately sized for a simple tool with one parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description adequately conveys the return value (list of liked projects) and the primary input (user ID). While it lacks alternative usage guidance or edge-case behavior, its simplicity makes this acceptable, and it is complete enough for basic invocations.
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 documents the single parameter 'id' as 'User ID' with 100% coverage. The description adds no extra parameter information, so it does not exceed the schema baseline. According to the rubric, a baseline of 3 is appropriate when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the specific resource 'projects liked by a user'. This distinguishes it from sibling tools like taiga_users_voted (items voted) and taiga_users_watched (watched items). The resource and action are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied: when you need to list projects a given user has liked. However, there is no explicit guidance about when to prefer this over alternatives like taiga_users_voted or taiga_users_watched, nor any exclusions or prerequisites. The intended scenario is reasonably clear from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It labels the action as 'resend' (a mutation) but does not disclose side effects, permission requirements, idempotency, or whether duplicate deliveries could occur. This leaves the agent unaware of potential consequences.
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, front-loaded sentence with zero filler. It clearly communicates the action and target in fewer than ten words.
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 tool with no annotations and no output schema, the description is too sparse. It does not explain what happens after the resend, prerequisites, or how failures are reported. The agent lacks sufficient context to predict behavior beyond the basic intent.
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 'id' parameter is described as 'Webhook log ID'). The description adds no additional parameter meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resend a failed webhook delivery' uses a specific verb (resend) and resource (failed webhook delivery). It clearly distinguishes this tool from siblings like webhooklogs_get (retrieve a log), webhooklogs_list (list logs), and webhooks_test (test a webhook configuration).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'failed webhook delivery' establishes clear context: use this when a delivery has failed and needs to be retried. However, it does not explicitly exclude alternatives or mention when not to use it, so it lacks the explicit alternative guidance seen in higher-scoring examples.
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, 'Stop watching a wiki page' only restates the tool's name and does not reveal any side effects, consequences, or details about what 'unwatch' entails (e.g., removing the current user from the watchers list, not deleting the page, or requiring authentication). The description adds no information beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and object. Every word is meaningful, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides sufficient context to understand the operation. It clearly identifies the resource and action, making it reasonably complete even though it does not elaborate on the expected result or edge cases. The simplicity of the tool reduces the need for more 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?
The input schema already fully describes the only parameter 'id' as 'Wiki page ID' (100% schema coverage). The description does not add any additional meaning to the parameter, so it meets the baseline of 3 but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Stop watching a wiki page' uses a clear verb ('Stop watching') and specific resource ('wiki page'), making the tool's purpose immediately obvious. It also distinguishes itself from sibling tools like taiga_wiki_watch, taiga_wiki_watchers, and other resource-specific unwatch tools.
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 its usage context (use when you want to stop watching a wiki page) but provides no explicit guidance on when to use it versus alternatives such as taiga_wiki_watch or taiga_wiki_watchers. It lacks a 'when to use' or 'when not to use' explanation, making it merely implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds the scoping behavior of filtering by project, which is useful, but it does not mention pagination, output format, or whether the project parameter is optional. The 'List' verb implies a read-only operation, but no explicit safety or behavior details are given.
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 exceptionally concise, with two short sentences that immediately convey the action and the optional filter. Every word contributes meaning, and there is no redundancy 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?
For a tool with low complexity, one parameter, and no output schema, the description is adequate but minimal. It does not explicitly state whether the project filter is required, nor does it describe the response shape, but the core purpose is clear enough for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single 'project' parameter as 'Project ID' with 100% coverage. The description's 'Filter by project' adds no new semantic meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'custom attribute definitions for epic,' specifying both the verb and the resource. This distinguishes it from sibling tools like taiga_epic_custom_attributes_values_get (which deals with values) and list tools for other entities.
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 phrase 'Filter by project' implies a use case, but there is no explicit guidance on when to use this tool versus alternatives or when not to use it. The intended usage is only implied by the tool's name and the description's 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 the full burden. It only states the action without disclosing side effects, prerequisites (e.g., items must exist), idempotency (e.g., what happens if already added), or error/return behavior. For a mutation tool, 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?
The description is a single, efficient sentence with no wasted words. It fits the purpose perfectly without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only 2 fully described parameters, but without annotations or output schema, the description does not explain what the caller should expect in response, error conditions, or any preconditions. It is adequate as a minimum viable description but leaves clear gaps in 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?
The input schema has 100% description coverage, with 'Epic ID' and 'User Story ID' clearly defined. The description adds no additional parameter semantics beyond the action itself, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a user story to an epic' uses a specific verb and identifies both resources (user story, epic), clearly distinguishing it from sibling tools like list, remove, or bulk_create. It precisely states the action performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the primary use case obvious: when you need to associate a user story with an epic. However, it does not explicitly mention alternatives (e.g., bulk_create for adding multiple) or exclusions, so it is clear but lacks explicit 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 full responsibility. It only states the action 'list' without disclosing return format, pagination, ordering, authentication requirements, or side effects (though read-only is implied). This adds minimal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no unnecessary words; it efficiently conveys the core action and resource.
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 one-parameter list tool with no output schema, the description is adequate but lacks details about the result structure, pagination, or any prerequisites. It doesn't compensate for the missing output schema explanation, but the operation is simple.
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 'epic_id' parameter, so the schema already documents it. The description does not add any additional meaning beyond the schema.
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?
Description uses specific verb 'List' with resource 'user stories related to an epic', clearly distinguishing from siblings like taiga_epics_list (lists epics) and taiga_userstories_list (lists all user stories).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear context: use when you need the user stories associated with a specific epic. No explicit exclusions or alternative tool suggestions, but the scope is evident from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states the action 'Delete' but does not disclose that deletion is irreversible, what happens to associated custom attribute values, or any permission requirements. The destructive nature is obvious but additional behavioral context is lacking.
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 filler. It directly states the action and resource without unnecessary words, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 delete tool, the description is functional but omits context about consequences, reversibility, or auth expectations. With no annotations and no output schema, the description could do more to complete the picture, making it only minimally adequate.
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 'id' already described as 'Custom attribute ID'. The tool description adds no further parameter-level meaning, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' and identifies the exact resource 'custom attribute definition for issue', clearly distinguishing it from sibling delete tools for epics, userstories, and tasks. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for issue' implicitly scopes usage to issue custom attributes, making it clear when to use this tool over the analogous delete tools for epics, userstories, or tasks. However, it does not explicitly mention alternatives or exclusionary conditions.
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 transparency burden. It only states 'List issue statuses' without disclosing whether project is required, what happens without the filter, or the return format. This leaves ambiguity in the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main action and resource. No unnecessary words or jargon.
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 list tool with one optional parameter, the description is mostly adequate. However, there is no output schema and no mention of default behavior without the project filter, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (project has a description), so the baseline is 3. The description adds 'Filter by project' which clarifies the parameter's role, but does not add new semantic details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('issue statuses'), with a specific filter ('by project'). It is distinct from sibling tools like taiga_issue_statuses_get (singleton) and taiga_issue_types_list (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear context: this tool lists issue statuses and can be filtered by project. However, it does not explicitly mention alternatives or when not to use it, but the context is sufficient for a simple list 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. It indicates a list operation, implying read-only behavior, but it does not mention return format, pagination, permissions, or any other side-effect details. Given the absence of an output schema, this leaves significant behavioral traits unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. Every word earns its place.
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 relatively simple, but the lack of annotations and output schema means the description should ideally clarify what the response contains. The schema fully documents the only parameter, and the action is clear, so it is minimally complete but with gaps around return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for the single parameter 'id' (type number, description 'Issue ID'). The description adds no additional semantic meaning beyond the schema, so the baseline score of 3 applies.
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 'List watchers of an issue' uses a specific verb ('list') and resource ('watchers of an issue'), clearly distinguishing it from sibling tools that list watchers of other resources (e.g., tasks, user stories). It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the use case: retrieving the watcher list for a particular issue. It does not explicitly contrast with alternatives like taiga_issues_voters or taiga_issues_watch, but for a simple read tool, the context is clear and no exclusions are needed.
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 disclosure burden. The verb 'Get' makes the read-only nature clear, and the addition of 'sprint' as an alternative term for 'milestone' adds context. However, it does not disclose return format, error behavior, or any access requirements, leaving some uncertainty for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the core functionality without any filler. It is appropriately concise for a simple get operation and leaves no waste.
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 (one parameter, no output schema), but the description lacks any mention of return value, required permissions, or relationship to other milestone operations. While the name and verb imply the retrieval of a full milestone object, the absence of an output schema places more burden on the description to explain the response. The coverage is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the single parameter 'id' as a 'Milestone ID' with a number type and required=true. The description's 'by ID' adds no additional semantic value beyond restating the parameter's purpose. With 100% schema coverage, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('milestone/sprint') with the method ('by ID'). This distinguishes it from sibling tools like taiga_milestones_list (which lists all) and taiga_milestones_create/update/delete, as it targets a single entity by its identifier.
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 phrase 'by ID' implies the tool is to be used when the agent possesses a specific milestone ID, which distinguishes it from listing operations. However, the description does not explicitly state when to prefer this over other milestone-related tools, nor does it mention exclusions or prerequisites (e.g., needing a project context or auth).
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 'Get a project by its ID', which is minimal. It does not mention read-only nature explicitly, error behavior (e.g., 404 if not found), permissions required, or the structure of the returned object. This is a significant gap given the lack of annotations.
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, clear, front-loaded sentence. Every word is useful and works for a simple get tool. It is appropriately sized and avoids unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get tool, the description is adequate but minimal. There is no output schema, so the agent is left to assume the return value is the full project object. It does not mention any caveats, such as required authentication, or clarify the difference from get_by_slug beyond the ID/slug distinction. It meets the minimum viability but has 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?
The schema describes the only parameter 'id' as 'Project ID' with 100% coverage. The description adds no extra meaning beyond the schema, essentially restating 'by its ID'. Baseline for high schema coverage is 3, and the description does not improve upon it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'project', and the method 'by its ID'. This distinguishes it from siblings like taiga_projects_list, taiga_projects_get_by_slug, and mutation tools. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you have a project ID. It clearly communicates the primary usage context without explicitly naming alternatives or exclusions, which is why it doesn't reach a 5. The sibling name 'taiga_projects_get_by_slug' further clarifies when not to use this tool, but the description itself does not mention it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It does add the useful implementation detail that the comment is posted via the history endpoint, but it omits side effects, return behavior, or permissions. This is not misleading, but it 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action, and contains no redundant wording. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two required parameters, but there is no output schema and the description does not explain what the response will be or how the history endpoint affects the outcome. The history-endpoint mention adds some context, but the description leaves room for more actionable 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?
The schema already provides 100% descriptive coverage for the two parameters (id and comment). The description adds no extra parameter-level meaning beyond what the schema states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Add a comment to a task,' a specific verb and resource that clearly distinguishes it from sibling comment tools for user stories, wiki, or issues. The added detail about the history endpoint does not confuse the core purpose.
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 should be used when adding a comment to a task, but it does not explicitly say when not to use it or mention alternatives like taiga_userstory_comment_create. There are no exclusions or prerequisite 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 the full burden. It only says 'Delete' without disclosing the destructive permanence, potential side effects on existing values, required permissions, or failure conditions. This is insufficient transparency for a deletion operation.
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 no filler. It conveys the essential action and target efficiently.
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 one-parameter delete tool, the description is adequate but lacks important context about the consequences of deletion (e.g., what happens to values assigned to tasks) and any response/return information. With no output schema, this leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter with a clear description ('Custom attribute ID'), so the baseline is 3. The tool description adds no extra parameter information, but the schema is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and identifies the resource ('custom attribute definition for task'), which clearly distinguishes it from sibling tools like custom attribute update/get or value tools. It is unambiguous about the scope (task custom attributes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the target ('for task'), providing clear context for when to use this tool vs. similar tools for epic/userstory/issue custom attributes. However, it does not mention alternatives or exclusions, so it misses the top score for explicit 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. It only states that it lists statuses with optional project filtering, but does not mention return format, ordering, required permissions, or any side effects. This is minimal for a read-only listing, but not wholly opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action, no redundant wording. It is concise and well-structured.
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 there is no output schema and only one optional parameter, the description is sufficient to invoke the tool, but it lacks context about the response shape or explicit differentiation from similar tools for other entity types. It is minimally complete for a straightforward list 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?
The schema already describes 'project' as 'Project ID' with 100% coverage. The description adds the important meaning that 'project' acts as a filter, clarifying its optional role. This goes slightly beyond the schema's plain field description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('task statuses'), clearly distinguishing it from sibling tools like create/update/delete and from userstory/issue status lists. The reference to filtering by project further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to retrieve task statuses and optionally filter by project, but it does not explicitly state when to prefer this over alternatives such as taiga_userstory_statuses_list or taiga_issue_statuses_list. No exclusions or alternative tool mentions are 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?
With no annotations, the description must convey behavior. It indicates a read operation ('Get') but does not disclose potential error handling, authentication requirements, or return format. It is not misleading, but it is minimal and lacks detail beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and resource. Every word contributes meaning; no redundant or extraneous content.
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 tool's low complexity and complete parameter schema, the description is adequate for basic understanding. However, with no output schema, it does not specify the return structure, and it lacks guidance on how this tool fits among numerous siblings (e.g., users_list, users_me), leaving some context 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?
The schema fully documents the only parameter 'id' with description 'User ID' (100% coverage). The description's phrase 'by ID' merely restates this without adding semantics like format, constraints, or example values. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the specific resource ('a user') with the method ('by ID'), which distinguishes it from sibling tools like users_list or users_me. This is a specific and unambiguous purpose.
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 does not explicitly state when to use this tool vs alternatives like users_list or users_me. However, the use case is naturally implied: retrieve a single user when the ID is known. No exclusions or alternative guidance 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 full responsibility for behavioral transparency. It discloses that the comment is posted via the history endpoint, but it omits key details such as authentication requirements, whether the action is destructive, or any side effects like notification triggering. The description does not indicate what happens to the userstory's history beyond the posting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence clearly states the primary action, and the second provides a useful implementation note. No wasted words or redundant repetition of the tool name.
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 tool with two well-documented parameters and no output schema, the description adequately explains the core purpose. However, it does not describe the return value or successful outcome (e.g., whether the created comment is returned, or if only success/failure is indicated). Given the low complexity, it is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both parameters (id and comment). The description adds no additional meaning beyond the schema, such as format constraints, examples, or relationships between parameters. Baseline of 3 is appropriate when schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource construction: 'Add a comment to a userstory.' It clearly distinguishes this tool from sibling comment tools for other entities (e.g., task, issue, wiki) and from the userstory comment deletion tool. The additional detail about the history endpoint reinforces the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is used for adding comments specifically to user stories, setting the context for when to use it. However, it does not explicitly mention when not to use it or provide alternatives (e.g., delete comment). This is clear context without exclusions, but not fully explicit usage 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 must carry behavioral information. It communicates that the tool lists definitions and can be filtered by project, but it does not disclose whether project is required, what fields the definitions contain, or whether pagination applies. The 'List' verb implies a safe read operation, which is some behavioral signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler; the purpose and filter behavior are immediately clear. Every word contributes.
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 one-parameter list tool without annotations or output schema, the description covers the essential purpose but leaves uncertainty about the return structure (attribute definitions fields) and how it relates to the sibling values_get tool. It is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the only parameter (project: 'Project ID'), and the description adds the semantic that it is a filter. However, this is minimal additional value beyond the schema, so the baseline of 3 applies.
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 states 'List custom attribute definitions for userstory' – a specific verb and resource. This clearly distinguishes it from sibling tools like taiga_userstory_custom_attributes_values_get (values) and taiga_epic_custom_attributes_list (different entity).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It includes 'Filter by project' as a usage hint, but does not explicitly state when to use this tool versus alternatives such as the values get/update tools or the epic/task/issue variants. No exclusions or alternative tool references 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. It only states the basic listing action and filter capability, without mentioning return format, pagination, authentication needs, or read-only nature. This is a minimal disclosure that leaves the agent uncertain about side effects or output structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action and no unnecessary words. It is highly efficient and earns its place.
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 tool with one optional parameter and no output schema, the description conveys the essential purpose and filter capability. However, it lacks any detail about the response format or behavioral nuances, which is a gap given the absence of annotations and output schema. It is minimally complete but not richly contextual.
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% (the 'project' parameter is described as 'Project ID'), so the baseline is 3. The description adds value by clarifying that the parameter is used for filtering ('Filter by project'), which is not explicitly stated in the schema.
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 'List wiki links' uses a specific verb and resource, clearly distinguishing it from sibling tools like taiga_wiki_list (which lists wiki pages) and taiga_wiki_links_get (which retrieves a single link). The added 'Filter by project' further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when listing wiki links) and mentions filtering by project, but it does not explicitly compare with alternatives or state exclusions. For example, it does not say 'use this instead of taiga_wiki_list' or note any conditions like 'only when a project is specified'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only restates the tool name without disclosing any behavioral traits such as read-only nature, response format, or authentication requirements. For a simple getter, some context beyond the name would be helpful.
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 no redundant words. It is appropriately minimal for a straightforward getter.
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 only one parameter and no output schema, so the description sufficiently communicates the tool's purpose. It specifies the entity type (issue) and action (get), which is complete for its simplicity, though it could mention that it returns the attachment's metadata.
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 the 'id' parameter described as 'Attachment ID', which is fully explicit. The description adds no additional meaning to the parameter, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Get') and resource ('specific issue attachment'). The word 'issue' distinguishes it from sibling attachment getters for epics, user stories, and tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies use when a specific issue attachment ID is known. However, it does not explicitly mention when not to use it or name alternative tools for other entity types, though the context is sufficient.
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 clearly states the destructive effect (removes user from project), but does not mention irreversibility, permission requirements, or potential side effects. It meets a minimal bar but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is immediately clear and free of any filler or redundant content. It earns its place without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation, the description plus schema are sufficient to invoke the tool correctly. It does not explain prerequisites like permissions or error handling, but given the simplicity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single required parameter 'id', described as 'Membership ID'. The description adds no further parameter semantics beyond what the schema already 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' with the resource 'membership' and adds a clarifying parenthetical '(remove user from project)'. This makes the action unambiguous and distinguishes it from sibling membership operations like create, update, get, or 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 states what the tool does but provides no explicit when-to-use vs alternatives. Usage is implied from the verb 'Delete', and there is no mention of when not to use it or how the membership ID should be obtained. This is acceptable but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'Get' strongly implies a read-only operation, but the description does not explicitly state side effects, authentication requirements, or behavior on not-found IDs. For a simple getter, this is minimally transparent but lacks explicit 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?
The description is a single, concise sentence with no redundant words. It directly states the action and object, making it easy to parse and front-loaded. Every word earns its place.
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?
Given the tool's simplicity (one fully-described parameter, no output schema), the description adequately covers the core invocation. However, it does not mention what is returned (the membership object) or any edge cases, which would be helpful since no output schema or annotations are present. Still, the minimal nature of the tool keeps it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of the single parameter, describing 'id' as 'Membership ID'. The description's phrase 'by ID' adds no additional semantic information beyond what the schema already states, so it meets the baseline for high 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 uses the specific verb 'Get' and the resource 'membership', and specifies the access pattern 'by ID'. This clearly distinguishes it from sibling tools like taiga_memberships_list, create, update, and delete, and accurately states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool instead of others, but the 'by ID' phrasing implies it is for retrieving a single membership when the ID is known. No exclusions or alternatives are mentioned, so the usage is only implicitly conveyed.
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 responsibility. It accurately labels the operation as a read ('Get'), but it does not disclose behaviors such as return format, error handling for non-existent slugs, or authentication requirements. For a simple read operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states exactly what the tool does with no filler. Every word earns its place.
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 tool with only one parameter and no output schema, the description covers the essential purpose. It doesn't explicitly state that a project object is returned or clarify error behavior, but these are largely inferable given the simple scope.
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 full coverage for the single parameter `slug` with description 'Project slug.' The tool description adds no additional meaning beyond confirming the slug is the lookup key, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Get' with the resource 'project' and specifies the distinguishing criterion 'by its slug,' clearly separating it from taiga_projects_get (by ID) and taiga_projects_list. This is precise and self-explanatory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a project slug is available, but it does not explicitly contrast with the alternative taiga_projects_get (by ID) or state when not to use this tool. Usage guidance is therefore merely implied rather than explicit.
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 itself must disclose behavioral aspects. It conveys that this is a read-only 'list' operation, which is transparent. However, it does not mention potential pagination, required permissions, or response structure, but these are not critical for a simple list operation.
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, direct sentence that immediately states the action and object. No filler or redundant information, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list-by-ID tool with a fully described schema, the description is adequate. It does not explain return format, but 'list voters' implies a collection of voters, and the tool's simplicity reduces the need for more 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?
The input schema has 100% description coverage for the single parameter 'id' as 'Task ID'. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'List' and resource 'voters of a task', making the tool's purpose unambiguous. It also naturally distinguishes this from sibling tools for epics, user stories, and issues by explicitly saying 'task'.
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 the list of voters for a given task ID. It does not explicitly compare to alternatives like watchers or upvote/downvote tools, but the simplicity of the operation makes the context clear enough.
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 burden. It merely says 'Get' which implies a read operation, but lacks context about authentication requirements, potential errors, or the data shape returned. Minimal 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. No unnecessary words or repetition.
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?
Given the simple nature of the tool (no params, no output schema), the description is fairly complete for invoking it. Could mention what 'user info' includes, but the purpose is clear enough for an agent to select and use it.
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?
Tool has zero parameters, so schema coverage is trivially 100%. Baseline for 0 params is 4; the description needs no parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and the resource (current authenticated user info). It distinguishes from sibling tools like taiga_users_get and taiga_users_list by emphasizing 'current authenticated', making it 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?
Usage is implied: use this tool when needing the authenticated user's own info rather than fetching a specific user by ID. However, no explicit alternatives or exclusions are mentioned, so the guidance is only implicit.
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 behavioral burden. 'Get' implies a read-only operation, but the description does not state whether it is read-only, what happens if not found, or any other behavioral traits. It simply restates the function.
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 8-word sentence with no filler. It is front-loaded with the verb and resource.
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?
Given this is a simple two-parameter lookup tool with no output schema or annotations, the description adequately states the purpose and required inputs. It does not explain return format, but that is not critical for a getter.
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 covers both parameters with descriptions ('User story ref number' and 'Project ID'), and both are required. The tool description's 'by ref and project' adds no new semantic meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'user story', and the identifying parameters 'by ref and project'. It distinguishes from sibling tools like taiga_userstories_get (presumably by ID) through the explicit 'by ref' qualifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: retrieving a user story when you have both its ref and project ID. It does not explicitly name alternatives or exclusions, but the 'by ref and project' context gives clear guidance on 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 burden of indicating safety. 'Get' clearly implies a read-only operation, but the description does not disclose any details about the response format, error behavior, or required permissions. For a simple retrieval tool, this is acceptable but not rich in behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant information. Every word contributes to the meaning, making it an exemplary model of conciseness.
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?
Given the simplicity of a get-by-id operation with one parameter and no output schema, the description suffices to convey the core functionality. It could be enhanced by specifying the structure of a webhook log entry or common use cases, but the tool's simplicity and the clear 'Get a webhook log entry' phrasing make the context reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single parameter 'id' as 'Webhook log ID' with 100% coverage. The description adds no additional semantic detail, merely restating that the lookup is by ID. Since the schema is fully self-explanatory, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a webhook log entry by ID' uses a specific verb ('Get') and clearly identifies the resource ('webhook log entry') and the selector ('by ID'). It unambiguously distinguishes this from sibling tools like taiga_webhooklogs_list or taiga_webhooklogs_resend, making the tool's purpose 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used when you have a specific webhook log ID and want a single entry, but it does not explicitly mention alternatives or when not to use it. No contrast is given with the similar list or resend tools, so the guidance is only implied by the 'by ID' phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description's verb 'Get' communicates that this is a read-only operation, which is a key behavioral trait. However, it does not disclose any additional details such as error behavior, return format, or required permissions, leaving the agent to assume standard GET semantics.
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 directly states the tool's purpose with no filler words. It is front-loaded and every word contributes to understanding, scoring high on conciseness.
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?
Given that this is a simple single-parameter GET tool with no output schema, the description adequately communicates the core purpose. It lacks explicit return-value information, but the tool name and description strongly imply the webhook object is returned, making it sufficiently complete for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full documentation for the only parameter 'id' with the description 'Webhook ID' (100% coverage). The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and specifies the resource 'webhook' with a clear selector 'by ID'. This unambiguously identifies it as a retrieval operation distinct from sibling tools like taiga_webhooks_list, taiga_webhooks_update, and taiga_webhooks_delete.
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 that the tool is used to fetch a single webhook when its ID is known, but it does not explicitly mention when to use it over alternatives such as taiga_webhooks_list for enumerating webhooks. There is no exclusion or prerequisite provided, making it adequate but lacking explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a read-only list operation and scoping by project, but does not disclose behavior when no project is given, pagination, or authentication requirements. This is moderate transparency for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and resource, and every word adds value. No unnecessary information is included.
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 is simple with one optional parameter and no output schema. The description adequately explains both the purpose and the filtering mechanism, which is sufficient for an agent to select and invoke the tool correctly. It doesn't mention return format, but that is often inferred for list operations.
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 schema includes the project parameter with description 'Project ID', but the description adds key meaning by stating it acts as a filter. This clarifies that the parameter is optional and scopes the results, going slightly beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists custom attribute definitions specifically for tasks, using a specific verb and resource. It distinguishes itself from sibling tools like taiga_epic_custom_attributes_list and taiga_userstory_custom_attributes_list by specifying 'for task'.
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 mentions an optional project filter, implying when to use the tool. However, it does not explicitly state when to use this over alternatives like values_get or create/update tools, nor does it mention any exclusions. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the read-only 'List' action and the project-filtering behavior, but it does not disclose output shape, pagination, ordering, or whether omitting project returns statuses from all projects. This is adequate but minimal for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler; the core action and filter are front-loaded. Every word earns its place.
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 low-complexity list tool with one optional parameter and no output schema, the description is mostly complete. It lacks an explicit statement of behavior when 'project' is omitted, but the tool is simple enough that this is a minor gap.
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 schema already provides 100% coverage for the single 'project' parameter as 'Project ID'. The description adds the semantic that this parameter acts as a filter, which is helpful but not a major addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and concrete resource ('userstory statuses'), clearly distinguishing this from related tools like taiga_userstory_statuses_get or task/issue status lists. The added 'Filter by project' further clarifies the operation's scope.
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 retrieving userstory statuses and optionally narrowing by project, but it does not explicitly state when to prefer this over taiga_userstory_statuses_get or other status list endpoints. There is no guidance on exclusions or alternatives, so usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. 'List' clearly implies a safe read operation, and 'Filter by project' discloses a scoping behavior. However, it does not mention pagination, response format, or any potential limitations, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains zero fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description adequately communicates the operation and the optional filtering. It could mention pagination or response contents, but the basic context is sufficient for this low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the 'project' parameter as a Project ID (100% coverage). The description adds value by stating 'Filter by project,' clarifying that this parameter is an optional filter rather than a required key or something else.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('webhooks'), clearly distinguishing it from sibling tools like create, get, update, delete, and test. The phrase 'Filter by project' adds a scoping detail that further clarifies its role.
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 when you need to list webhooks, optionally filtering by project. However, it provides no explicit guidance on when to use this tool versus alternatives (e.g., taiga_webhooks_get for a single webhook), nor any exclusions.
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:

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

Score Badge

Copy to your README.md:

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

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