Taiga MCP Server

Server Quality Checklist

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

Latest release: v1.0.1
Disambiguation5/5
Every tool targets a distinct resource and action, even the convenience wrappers (user_story_assign_milestone, issue_set_classification) are clearly specialized and documented. The only near-overlap (single vs bulk create) is explicitly distinguished.
Naming Consistency4/5
The overwhelming majority follow a clear `<resource>_<action>` snake_case pattern (e.g., task_get, project_create, milestone_delete). However, a few deviate: `search`, `ref_resolve`, `taiga_raw_request`, and the `batch_create_*`/`*_filters_data` tools, mixing verb-first and modifier-first ordering.
Tool Count2/5
70 tools is excessive for an agent to choose from, even for a full-featured project management API. While each tool has a purpose, the server could have consolidated CRUD operations (e.g., a generic `list_<type>`) to reduce clutter.
Completeness4/5
CRUD is covered for all main entities (projects, epics, user stories, tasks, issues, milestones, wiki pages, memberships) plus comments, attachments, votes, watches, search, and reference resolution. Some niche Taiga features (import/export, webhooks) are only reachable via the raw-request escape hatch, but the core domain is well covered.
Average 4/5 across 70 of 70 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 24 commits in the last 12 weeks
- Last stable release on August 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read, non-destructive write operation, so no contradiction exists. However, the description adds no behavioral context such as side effects, required permissions, or idempotency implications beyond what annotations provide.
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 one-sentence description is short but under-specified. It is not effective conciseness; it omits critical information needed for a 3-parameter creation tool.
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 three parameters, no output schema, and no parameter descriptions, the description is far too sparse. It fails to explain required inputs, optional field behavior, or expected return, making it inadequate for reliable tool 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 0%, and the description mentions none of the three parameters (name, is_private, description). It provides no meaning or defaults, forcing the agent to rely solely on bare schema fields.
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 project.' simply restates the tool name and title without adding any detail. It does not distinguish this creation tool from sibling tools beyond the action verb already present in the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, when not to use it, or any prerequisites. The description only states the action without providing 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?
Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive. The description merely repeats the word 'create' and adds no additional behavioral context such as return values, side effects, or permission requirements. With annotations present, the description contributes nothing beyond them.
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 uninformative sentence that essentially restates the title. While it is short, it is under-specified rather than effectively concise; it 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.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, 2 required fields, nested objects, and no output schema, a one-sentence description is wholly inadequate. It does not mention required inputs, creation behavior, or expected results, forcing the agent to infer everything from the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions no parameters. With 9 parameters and only 33% schema description coverage, the description should compensate for the undocumented fields but entirely fails to do so. The schema's sparse descriptions for points, watchers, and assigned_to are the only guidance, leaving most parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Create') and the resource ('user_story'), which distinguishes it from sibling tools like user_story_update or user_story_delete. However, it is extremely terse and lacks any scope or contextual detail, leaving it only minimally helpful.
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, what prerequisites exist (e.g., a valid project and subject), or how it compares to other create tools like task_create or issue_create. The description provides zero 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?
Annotations already indicate the tool is mutating, non-idempotent, and non-destructive. The description adds no extra behavioral context—nothing about return values, side effects, or validation requirements. It simply restates the operation without enriching the annotation-provided safety profile.
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 sentence with no fluff, but it is under-specified. It earns minimal value beyond the title and does not front-load any useful context. It is concise but not appropriately sized given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex create tool (11 parameters, 5 required) with no output schema and sparse annotations. The description is far too brief to give an agent a complete picture: it doesn't explain what an issue is, what the required fields are, how to obtain valid IDs, or what the tool returns. The agent would need to make many assumptions.
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 schema description coverage at only 45%, the description should compensate by explaining parameter meaning, but it says nothing about any parameters. It doesn't list required fields (project, subject, type, priority, severity) or clarify that type/priority/severity are Taiga IDs. The agent must rely on incomplete schema descriptions and guess at common concepts like 'status' or 'milestone'.
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 object (issue), making the tool's basic purpose unambiguous. It doesn't include any scope that differentiates it from other create tools (epic_create, task_create), but the noun 'issue' provides reasonable 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?
There is no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing an existing project, or contrast with issue_update/issue_delete. The agent is left to infer usage 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?
The description offers no behavioral details beyond what annotations already provide (readOnlyHint=false, destructiveHint=false). It does not disclose side effects, required permissions, or handling of duplicate milestones. The description adds no extra context to the annotation set.
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 only one sentence, so it is very concise with no fluff. However, it is under-specified; it repeats the title almost verbatim and provides no additional structure or information that would help 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?
For a create tool with four required parameters and no output schema, the description is incomplete. It does not explain return values, side effects, or how this tool fits among many siblings. The lack of behavioral and parameter information makes it difficult to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the four parameters. The input schema covers only two parameters with descriptions (estimated_start, estimated_finish), leaving name and project undocumented. With 50% schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource ('Create a new milestone'), which is specific enough to identify the tool's core function. However, it does not add any contextual scope (e.g., that it operates within a project) or differentiate itself from sibling create tools beyond naming the 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?
There is no guidance on when to use this tool versus alternatives. It simply says 'Create a new milestone' without mentioning prerequisites, exclusions, or when another tool (like milestone_update or milestone_delete) 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?
The annotations indicate a non-readonly, non-idempotent, non-destructive operation, but the description adds no behavioral detail beyond 'create a new task.' It does not disclose that repeated calls may create duplicates, that a user_story must exist, or any error conditions. The description should add context like idempotency warnings but doesn't.
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 one short sentence with no fluff, so it is concise. However, it front-loads only the basic purpose and omits necessary context. It is not bloated, but the brevity leaves out valuable 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 9 parameters, 3 required, and no output schema, the description is significantly incomplete. It fails to mention the required user_story parent, the project requirement, or the relationship to batch_create_tasks. The combination of sparse description and incomplete schema leaves a complex tool poorly documented.
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 covers 33% of parameters with descriptions (user_story, watchers, assigned_to), but the tool description itself mentions zero parameters. Required fields like project and subject have no explanation in the description or schema, and the description does nothing to compensate for the low schema coverage. This makes it hard for an agent to know what values are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new task.' clearly states the action (create) and resource (task), which distinguishes it from task_update, task_delete, and task_get. However, it does not differentiate from the sibling batch_create_tasks, which also creates tasks, and the description could be more specific about creating a single 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 mention when to use this tool instead of batch_create_tasks or task_update, nor does it state prerequisites such as the required user_story. This leaves the agent without direction on 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?
The description simply restates the action without disclosing behavioral traits such as sending an invitation, handling of existing users, or side effects. The annotations indicate it's a write operation with possible open-world effects, but the description doesn't elaborate.
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, brief sentence with no unnecessary words. However, it is under-specified, which slightly reduces its value as a concise 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 and with only a minimal description, this tool is not fully documented. It doesn't explain return values, the relationship between email and username, or edge cases like duplicate memberships.
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 does not mention any parameters. The input schema covers role, email, and username, but project lacks a description. With 75% schema coverage, the description doesn't compensate for the missing project 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 clearly states the action (create) and resource (membership), and the title adds 'Project Member'. It distinguishes from sibling tools like membership_update and membership_delete, but it's minimal and doesn't explicitly note it's for a single membership vs bulk 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 membership_bulk_create or membership_update. The description lacks any context about prerequisites 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?
Annotations indicate readOnlyHint=false (write operation) and idempotentHint=false, but the description adds no behavioral context beyond restating that it creates a page. There's no mention of duplicate slug handling, permissions, or side effects, so it fails to disclose anything beyond what annotations 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, concise sentence: 'Create a new wiki_page.' It is efficiently front-loaded and wastes no words. However, it is so minimal that it borders on under-specification, but for pure conciseness it earns a 4.
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 tool with three required parameters and no output schema, this description is inadequate. It doesn't explain expected return values, possible errors, or usage context. Given sibling tools like wiki_page_update and wiki_page_delete, the description is too sparse to fully inform an agent on how to use 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 33% (only 'slug' has a description), and the tool description provides no parameter information. The description doesn't clarify what 'content' should contain or that 'project' is an ID, leaving the agent with insufficient meaning for two of three 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 states the verb 'Create' and the resource 'wiki_page', making it obvious that this tool creates a wiki page. It distinguishes from sibling wiki operations (get, update, delete, list) by the create action, though it doesn't mention any specific scope or unique behavior.
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 like needing an existing project or how it relates to wiki_page_get_by_slug or other wiki tools. The usage is only implied by the word '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?
Annotations already provide safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds no additional behavioral context, such as whether linking replaces an existing relationship or how duplicate links are handled, so it does not go beyond what annotations 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 a single, front-loaded sentence that wastes no words. It conveys the core purpose instantly and is appropriately sized 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 two-parameter tool with no output schema, the description is adequate but leaves gaps. It does not mention what the operation returns or what happens in edge cases (e.g., already linked), though annotations help by indicating non-destructive and idempotent 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 both parameters: 'id' as Epic id and 'user_story' as User story id to link. The description adds only the word 'existing', which slightly implies a precondition but does not meaningfully 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 'Link an existing user story to an epic' clearly states the action (link) and the resources involved (user story, epic). It is specific and distinguishes from sibling tools like epic_unlink_user_story, which performs the opposite operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 epic_unlink_user_story or epic_related_user_stories. It does not mention prerequisites like whether the epic or user story must exist, nor any conditions for when linking is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. However, the description adds no additional behavioral context, such as rate limits, error handling, or response shape, beyond restating the tool's basic action. No extra value beyond 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, front-loaded sentence with no wasted words. It is appropriately sized for a simple get-by-id operation, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 params, 1 required, no output schema), the description combined with the rich schema and annotations is complete. The verbosity parameter's behavior and defaults are fully explained in the schema, so the description need not repeat them.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 clear descriptions for both 'id' and 'verbosity'. The description adds no additional 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 'Get a single issue by id' uses a specific verb and resource, clearly distinguishing it from issue_list (multiple issues) and other entity getters like task_get or user_story_get. The word 'single' and 'by id' precisely defines 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 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 like issue_list. It does not mention exclusions, prerequisites, or scenarios where another tool would be more appropriate. Usage is only implied by the tool's name and basic purpose.
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?
Annotations already provide the safety profile (readOnlyHint=false indicates mutation, destructiveHint=false indicates non-destructive, idempotentHint=true indicates safe retries). The description adds minimal context beyond the schema, mainly the ownership qualifier 'your vote.' No contradictions with annotations, but it does not elaborate on error behavior 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, front-loaded sentence with no filler or redundant information. It efficiently conveys the action and target.
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 2-parameter tool with no output schema, the description is underexplained. It omits the crucial relationship between 'id' and 'resource', fails to state what happens if the vote does not exist, and does not mention that the operation affects only the current user's vote. Annotations cover safety but not these operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It partially explains the 'resource' parameter by listing allowed values, but it does not clarify the meaning of 'id' — the critical fact that it is the ID of the resource (epic/story/task/issue) rather than a vote ID. This is a significant gap for correct invocation.
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 ('Remove') and the object ('your vote'), with the target resource types explicitly listed ('epic, user story, task, or issue'). This is a specific verb+resource+scope that unambiguously distinguishes it from vote_add.
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 (use when you want to remove a vote) but provides no explicit guidance on when to use this tool versus vote_add or when not to use it. It also does not clarify prerequisites, such as whether the user must have previously voted or whether the resource must exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 adds no behavioral context beyond what the annotations already provide (readOnlyHint=true, openWorldHint=true). It merely restates the title in a slightly expanded form. There is no mention of response handling, error cases, or the verbosity option's effect, which could be useful 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, front-loaded sentence with no unnecessary words. It is concise and immediately communicates the tool's function.
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?
This is a low-complexity, read-only tool with a well-documented schema and annotations. The description sufficiently conveys the core purpose, and the schema covers parameter nuances like verbosity. It relies on the schema for details, which is acceptable given the rich schema and annotations. A mention of what the response represents (the epic object) could add a bit more completeness, but it is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 both parameters: 'id' is described as 'Resource id' and 'verbosity' has a detailed explanation of its values and behavior. The tool description itself does not add any 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.
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 ('epic'), and specifies the retrieval mechanism ('by id'). It distinguishes from sibling tools like epic_list (which lists multiple epics) and epic_create/update/delete (mutations).
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: use this when you have a single epic id and need that epic's details. However, it does not explicitly state when not to use it or mention alternatives like epic_list for browsing or searching. No exclusions or alternatives are provided, so 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate safety. However, it adds no extra behavioral context (e.g., error cases, authentication, response shape) beyond the annotation-covered traits. Neutral, as no contradiction exists.
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 sentence with no padding. Every word is essential; it fully captures the action, resource, and scope. This is ideal conciseness for a simple get operation.
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-resource fetch, the description combined with rich annotations and complete schema coverage is largely sufficient. It lacks an explicit mention of the return value, but that is implied by 'Get'. The verbosity parameter effects are covered in the schema, so no critical gap exists. A slightly higher score would have required explicit mention of the response format or when to use minimal vs full verbosity.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 itself adds no parameter-specific meaning; the baseline of 3 applies because the schema handles the heavy lifting. The verbosity parameter's semantics are fully explained 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 uses a specific verb ('Get') and resource ('milestone') with a clear scope ('by id'). It distinguishes from siblings like milestone_list (plural) and milestone_stats by explicitly targeting a single resource by identifier.
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 (e.g., milestone_list, milestone_stats). It does not state prerequisites such as requiring a valid id, nor does it mention the verbosity parameter's role in tailoring responses. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare idempotentHint=true and destructiveHint=false, which covers key behavioral traits. The description adds no further context about side effects, error handling, or what happens if the resource is not already watched. It does not contradict the annotations, but it also does not enrich them.
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 covers the action and supported resource types. It is front-loaded and has no wasted words, making it 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 unwatch action with only 2 parameters and no output schema, the description is minimally acceptable but leaves gaps. It does not mention side effects (e.g., whether it only affects the current user) or error cases (e.g., unwatching a non-watched resource). More context would improve completeness, but the core action is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does enumerate the resource types, but these are already in the schema's enum. The 'id' parameter is not explained at all (e.g., what it refers to or how it is used), and the description simply restates what the schema already provides without adding meaningful 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 is specific and clear: 'Stop watching an epic, user story, task, issue, milestone, or wiki page.' The verb 'stop watching' is unambiguous and the resource types are fully enumerated, distinguishing it from sibling tools like watch_add and other mutating 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 usage (you use it when you want to stop watching one of the listed resources), but it does not explicitly state when to use it versus alternatives (e.g., watch_add) or any prerequisites such as needing to currently watch the resource. It is not misleading, but 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?
Without annotations, the description carries full burden, but it only states the operation without disclosing behavioral details such as required permissions, error handling, or whether it is strictly read-only. The verb 'Get' implies non-destructive behavior, but this is 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 sentence with no redundant information, efficiently conveying the tool's 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?
While the tool is simple, the lack of an output schema and annotations means the description should provide more context about the return value or error cases. The existing description covers the core purpose but 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 description adds meaning to the 'slug' parameter by noting it is 'project-scoped', which explains the need for the 'project' parameter. However, it does not elaborate on the format of the slug or the exact meaning of the project integer, leaving some ambiguity.
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 ('Get'), the resource ('wiki page'), and the unique key ('project-scoped slug instead of its numeric id'), distinguishing it from the sibling wiki_page_get tool that likely uses numeric IDs.
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 'instead of its numeric id' provides clear guidance on when to use this tool—when a slug is available—and implies the alternative method for ID-based lookups. It does not explicitly name the sibling tool, but the contrast 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is known. The description adds the response shape '{ items, pagination }', which is useful, but does not disclose ordering, default page size behavior, or error cases. It does not contradict 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 two concise sentences with no filler. It front-loads the primary purpose and directly states the response envelope, earning its place without redundancy.
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 five parameters, no output schema, and the presence of annotations, the description is mostly complete. It explains the resource scope and the response shape, and the schema covers parameter details. It could mention the required fields (resource, object_id) but they are visible in the schema, so the description is sufficient for 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?
Schema description coverage is 80%, with detailed descriptions for page, page_size, and verbosity, plus enums for resource and verbosity. The description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline 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 uses the specific verb 'List' and names the resource type 'attachments' along with the parent resource types (epic, user story, task, issue, wiki page). This clearly distinguishes it from sibling tools like attachment_upload, attachment_download, and attachment_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 the use case (listing attachments on a given resource) but does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or prerequisites. There is no comparison to sibling tools such as comment_list or wiki_page_list.
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?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description is consistent with these but adds no extra behavioral context (e.g., that the user story and epic remain unchanged). No contradiction.
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. Every word is necessary, with no waste or verbosity.
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 unlink operation with two parameters and supportive annotations, the description adequately conveys the core purpose. It could be improved by noting that the entities remain unchanged, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 having clear descriptions in the schema. The tool description adds no additional meaning 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 a specific verb ('unlink') and clearly identifies the action and resources ('user story from an epic'). It distinguishes itself from sibling tools like epic_link_user_story (opposite action) and epic_related_user_stories (listing).
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 one needs to remove a user story-epic association, but it does not explicitly state when to use this tool versus alternatives. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, which covers the safety profile and open-world expectations. The description adds no further behavioral context—such as authentication requirements, response size implications, or side effects—so it neither enhances nor contradicts the 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, focused sentence that delivers the essential purpose without any filler words, redundant details, or unnecessary context. It is optimally concise 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?
For a simple read-only get-by-id tool with 100% schema coverage and clear annotations, the description is nearly complete. It lacks a brief note on when verbosity might matter, but this is already captured in the schema, so the description adequately supports tool selection and invocation for this low-complexity 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 fully documents both parameters: id (integer) and verbosity (enum with detailed explanation of trims and defaults). The description restates that it fetches by id but adds no additional meaning beyond the schema, so 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 verb (Get), the resource (single user_story), and the key parameter (by id). It distinguishes this tool from siblings like user_story_list (multiple stories) and user_story_create/update/delete, so an agent can easily select it for single-record retrieval.
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 this tool is for fetching a specific user story when the id is known, but it provides no explicit guidance on when to use this instead of user_story_list or other alternatives. No exclusions or alternative tool names are mentioned, leaving usage to inference.
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?
Annotations already declare idempotentHint=true, openWorldHint=true, and destructiveHint=false, which cover the side-effect profile. The description adds the context that the tool sets up 'update notifications,' which is useful, but it does not elaborate on other behaviors (e.g., how notifications are delivered or how to remove the watch). No contradiction with 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?
A single, well-structured sentence that front-loads the verb and resource list. No wasted words or redundancy.
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 a clear enum schema and annotations covering safety and idempotency, the description adequately explains the purpose and scope. It does not mention how to unsubscribe (watch_remove) or any prerequisites, but these are not essential for understanding this tool. The absence of an output schema reduces the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 0% description coverage, so the description should compensate. It does list the valid resource types, which matches the enum in the schema, but it gives no explanation of the 'id' parameter. Since the resource enum is self-explanatory and the tool is simple, the description provides marginal added 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 specifies the action 'Watch' and lists all supported resource types (epic, user story, task, issue, milestone, wiki page) with the purpose 'for update notifications.' It clearly distinguishes from sibling 'watch_remove' by implying an add/subscribe operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the user wants to receive updates on a resource, but it does not explicitly state when to use this tool versus alternatives like 'vote_add' or 'watch_remove.' 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation. The description adds minimal context beyond the schema, such as "single" resource and "by id" retrieval, but does not describe response format, error behavior, or authorization requirements. With annotations covering the safety profile, 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 with no fluff. It states exactly what the tool does and is appropriately sized for a simple get-by-id operation, earning its place without any 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?
Given the tool's simplicity (2 params, 100% schema coverage, annotations for read-only), the description provides sufficient context for correct invocation. It clearly identifies the resource and key parameter (id), and the verbosity parameter is fully explained in the schema. While it does not mention return values or disambiguate explicitly from wiki_page_get_by_slug, the "by id" phrasing covers the most likely confusion. This makes it nearly complete for a simple 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 input schema has 100% description coverage, including a detailed explanation of verbosity with enum meanings. The tool description adds no extra parameter semantics, so the baseline of 3 applies; the schema itself does 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 "Get a single wiki_page by id" clearly specifies a verb (get), a resource (wiki_page), and a scope (single by id). This unambiguously distinguishes it from siblings like wiki_page_get_by_slug and wiki_page_list, which are separate 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 usage through the phrase "by id": if the agent has a resource id, this tool is the appropriate choice. However, it does not explicitly state when not to use it or name alternatives such as wiki_page_get_by_slug, leaving the contrast to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, but the description adds meaningful behavioral details: it returns base64 content along with metadata and rejects files larger than 10485760 bytes before downloading. This goes beyond the annotation and is consistent with read-only 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 two concise sentences with no filler. It front-loads the action and provides key output and error details efficiently.
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?
Without an output schema, the description covers the return payload and a critical size-based rejection condition. However, it does not explicitly state that resource and id together identify the attachment, which is important since `resource` is undocumented in the schema. Overall, it is adequate for a simple download 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?
Schema description coverage is only 50% (id has a description, resource does not). The tool description does not clarify the roles of `resource` and `id` or how they identify the attachment, nor does it add any parameter-level detail. The description focuses on return values, not input semantics, so it fails to compensate for the schema 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 the action (download), the target (attachment file contents), and the output format (base64 plus filename, content type, size, sha1). It distinguishes the tool from sibling attachment_upload and attachment_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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent needs to fetch an attachment's file contents, but it does not explicitly state when to use this tool instead of alternatives like attachment_list or attachment_upload. No when-not 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description aligns with these but adds no extra behavioral context (e.g., error handling, response shape). It is consistent but not additive.
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 sentence, no filler, and the key action is 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only getter with only 2 parameters and full schema documentation, the description is complete. It doesn't need to explain return values since there is no output schema, and the annotation covers safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 verbosity parameter richly documented. The description adds no parameter-level meaning beyond what the schema already provides, 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 uses a specific verb+resource ('Get a single task by id'), clearly distinguishing it from sibling tools like task_list, task_create, and task_update. It precisely conveys the tool's scope 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?
Usage is implied: retrieve one task by id. However, there is no explicit guidance on when to prefer this over task_list or other retrieval tools, and no mention of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-read-only, non-destructive, idempotent operation. The description adds valuable context about partial patch behavior and automatic handling of Taiga's version field, which goes beyond the annotations without contradicting them.
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, well-structured sentence that front-loads the core action and immediately explains the partial patch behavior. Every word earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, nested objects, no output schema, and low schema coverage, the description is too sparse. It does not mention return values, error behavior, or how to handle nested points, leaving the agent with significant ambiguity for a complex update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, and the description does not explain individual fields beyond telling users to include only changed ones. It adds general patch guidance and a version caveat, but fails to compensate for the many undocumented parameters like points, tags, and subject.
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 'Update' and the resource 'existing user_story', distinguishing it from create/delete/list siblings. It also specifies partial patch semantics, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for modifying an existing user story and clarifies that only changed fields need to be included. While it doesn't explicitly name alternatives like user_story_create, the context is clear from the sibling tools and the 'existing' qualifier.
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?
Annotations already cover non-destructive, read-only=false, idempotent hints. Description adds 'Not gated' (no permission barrier) and reassures editing is not destructive, but does not disclose replacement semantics or error behavior. Some value beyond 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?
Two concise sentences: first states the action and resource scope, second provides a safety note. No filler or redundancy.
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 update tool with no output schema and good annotations, the description covers purpose and safety adequately. It doesn't explain how to obtain comment_id or that text is fully replaced, but schema and sibling comment_list imply these, meeting the needs of a straightforward CRUD operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes id, comment, and comment_id; resource enum is self-explanatory. Description adds no additional parameter-level meaning, maintaining baseline 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?
Uses specific verb 'edit' with explicit resource 'comment' and scope (epic, user story, task, issue). Clearly distinguishes from comment_add and comment_delete by focusing on modifying existing text.
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?
Implies when to use: to change text of an existing comment, as opposed to adding or deleting. Though alternatives are not named, the verb and object make the use case unambiguous. No exclusions or prerequisites stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint and openWorldHint, so the description adds value by disclosing the response shape ({ items, pagination }) and pagination fields (count, current_page, has_next) plus the default page_size of 30. This goes beyond the annotations and gives the agent a clearer picture of the tool's 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 is two sentences, front-loaded with the core purpose, and includes essential behavioral details (response shape, pagination, default page_size) without unnecessary fluff. Every sentence contributes value.
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 no output schema, the description explains the response envelope and pagination. The schema covers parameter details, and the verbosity parameter description clarifies field levels. It lacks explicit error or edge-case handling, but given the low complexity and read-only nature, it is sufficiently 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 detailed parameter descriptions (page, project, page_size, verbosity). The description only says 'optionally filtered by the given query parameters' and mentions default page_size, which is already in the schema. Thus it adds no significant semantic 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 states 'List memberships' with a clear verb and resource, and the title 'List Project Members' reinforces this. It is clearly distinguished from sibling tools like membership_get, membership_create, etc., by the verb 'list' and the project-membership 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 gives no explicit 'when to use' or alternative guidance. It implies use for listing project memberships, but does not mention using membership_get for a single member or caution against using it for mutation. The 'optionally filtered' phrase hints at list scenarios but doesn't provide exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses what data is returned (total/completed points, user stories, tasks, per-day breakdown) but does not explicitly confirm a read-only operation, mention permissions, or describe error behavior. This is a moderate 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, focused sentence with no redundancy. The main verb 'Get' is front-loaded, and each detail (points, user stories, tasks, per-day) 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?
This is a simple read tool with one parameter and no output schema. The description adequately covers the response contents (stats breakdown), which is sufficient for an agent to select and invoke it correctly. Minor gaps like metric definitions are not critical for 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 input schema fully describes the single 'id' parameter as 'Milestone id' (100% coverage). The description adds no additional parameter context, 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 function: 'Get burndown/points stats for a milestone (sprint)'. It lists specific metrics (total and completed points, user stories, tasks, per-day breakdown), distinguishing it from sibling tools like milestone_get which would retrieve general milestone data.
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 use case evident: use this tool when you need burndown or points statistics for a sprint. It does not explicitly name alternatives or exclusions, but the focused scope implies when it should be used, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read with no workspace restrictions. The description adds no extra behavioral context (e.g., pagination, auth, rate limits), but none is needed for a simple getter with verbose schema.
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 fluff. It says exactly what the tool does in as few words as possible while remaining informative.
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 getter with rich schema and annotations, the description is adequate. The schema covers all parameter semantics, annotations cover safety and scope, and the tool name implies the return object. Minor gap: no explicit mention of return format or error behavior, but that is not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'id' and 'verbosity' fully explained in the schema. The description itself adds no parameter detail, so baseline 3 is appropriate; it doesn't reduce 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 uses a specific verb+resource pattern ('Get a single project by id'), clearly distinguishing this from siblings like project_list (plural) and project_create. The word 'single' makes the scope explicit.
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 a clear usage context: fetching one project by its id. It does not explicitly mention alternatives or exclusions, but the context is unambiguous for a single-resource getter, and sibling names like project_list imply the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=true and openWorldHint=true, and the description adds useful context about the response structure ({ items, pagination }), pagination fields, and default page_size (30). This goes beyond the annotations, though it does not cover potential edge cases like empty results or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences), front-loaded with the primary action, and every sentence adds value. It efficiently communicates the action, filtering option, and response format without redundancy.
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 no output schema, the description adequately explains the response envelope and pagination details. The parameter details are fully covered by the schema, and the tool's simplicity (list with optional filters) means the description is sufficient for an agent to understand usage and 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 coverage is 100% with all parameters described in the input schema. The description adds little beyond mentioning that filtering is possible; the default page_size is repeated from the schema. No meaningful semantic addition is provided.
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 projects, with optional filtering via query parameters. The verb 'list' and resource 'projects' are specific, and the distinction from sibling tools like project_get is evident from the name and action.
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 projects (optionally filtered) but does not explicitly state when to use this tool versus alternatives like project_get for a single project. It provides clear context but no 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits on its own. It clearly states the mutating action (moving) and the special behavior of omitting milestone to remove the story. However, it does not mention potential side effects, required permissions, or error conditions, 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 concise sentences with no wasted words. It front-loads the core purpose and includes the key usage nuance without redundant detail.
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 tool with full schema coverage, the description is largely complete: it explains the operation, the special case for removal, and the relationship to user_story_update. It does not describe return values, but since there is no output schema, an explicit note about the return type could 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 of parameter meanings, so the baseline is 3. The description reinforces the milestone-omission behavior but does not add significant new semantics beyond what the schema already states.
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 ('Move') and identifies the exact resource (user story into a milestone/sprint). It also distinguishes this tool from its siblings by explicitly describing it as a convenience wrapper over user_story_update, making its 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates when to use the tool: to move a user story into or out of a milestone. It names the alternative (user_story_update) as the underlying general operation, but does not explicitly state when not to use this tool versus that alternative, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true, the safety profile is already established. The description adds valuable behavioral details: the response shape { items, pagination }, pagination fields, default page_size, and that data is read from Taiga. This goes beyond annotations without contradicting them.
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?
Three sentences with no fluff. Front-loaded with the core purpose, then response structure and a practical hint. Every sentence earns its place without 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 description covers key aspects like response format, pagination, and a usage hint, but lacks explanations for several query parameters (q, status, epic, milestone) and does not fully clarify the return payload beyond the basic structure. Given no output schema, more detail on parameter meanings would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description does not fully compensate. It explains pagination-related parameters (page/page_size) via the response shape and default, but leaves q, epic, status, and milestone undefined. It also references 'tags/assigned_to' which are not in the schema, adding confusion rather than 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 uses a specific verb 'List' and resource 'user_storys', and clarifies optional filtering by query parameters. It clearly distinguishes from sibling tools like user_story_get by focusing on listing rather than retrieving a single item.
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 clear context that this tool lists user stories with optional filters and pagination. Explicitly recommends user_story_filters_data for discovering valid filter values cheaply, which serves as an alternative for exploration. Does not explicitly state when not to use, but the context is clear.
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?
Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, covering safety and mutation traits. The description adds resource scope but doesn't elaborate on idempotent behavior or side effects, so it provides minimal extra transparency beyond 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?
Two short sentences immediately state the action and resource constraints with no filler. Every word adds value and the structure is ideal for a simple 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 two-parameter tool with simple semantics, the description, combined with annotations and the enum schema, is nearly complete. The absence of an output schema is acceptable since the outcome of an upvote is straightforward.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the 'resource' parameter by listing the supported types and explicitly calling out unsupported ones. However, it provides no information about the 'id' parameter, and schema coverage is 0%, leaving that parameter reliant on inference.
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 'Upvote' and clearly enumerates the resource types (epic, user story, task, issue). It distinguishes from the sibling 'vote_remove' by the opposite action even without naming it.
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 which resources support voting and excludes milestones and wiki pages. It doesn't mention alternatives like 'vote_remove' for removing a vote, but the guidance is clear enough for selecting the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the response envelope ({ items, pagination }), the pagination fields, and the default page_size of 30. This adds useful context beyond the readOnlyHint annotation, which only signals a safe read operation. No contradiction with 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 two tight sentences that front-load the core action and follow with the response structure. No wasted words or redundant phrases.
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 list tool with 4 well-documented parameters and a readOnlyHint, the description is fairly complete: it explains the response shape and pagination behavior. It could explicitly state that the project parameter is required to scope results, but the schema already marks it as required.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 description mentions 'optionally filtered by the given query parameters' but does not add meaning to individual parameters beyond what the schema already provides. The mention of default page_size restates the schema's own default.
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 names the resource 'wiki_pages', clearly distinguishing it from sibling tools like wiki_page_get or wiki_page_get_by_slug. It also mentions optional filtering and the response shape, making the tool's function 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 pages with optional filters, but it does not explicitly contrast with alternatives like wiki_page_get_by_slug or wiki_page_get. There is no 'when not to use' guidance, though the title and sibling names make the purpose fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that this is a non-read-only, non-destructive, non-idempotent operation. The description adds valuable behavioral context beyond annotations by specifying that file contents must be passed as base64, which is a critical encoding requirement for invocation.
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 long, front-loads the core action, and contains no filler or redundant detail. Every sentence adds necessary 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?
There is no output schema, so the description should at least hint at the expected return value or success behavior, but it does not. It also omits any mention of error conditions, size limits, or authentication requirements. For a mutation tool with 7 parameters and no output schema, the description leaves meaningful 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 description coverage is only 43%, and the description does not compensate much. It repeats that file contents are base64 (already in the schema) and lists target resource types (already in the enum). It does not explain parameters like 'project' or 'file_name' beyond what the schema already provides, leaving the agent to infer their meaning.
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 ('Upload') and a clear resource category ('file attachment'), and lists the target entity types (epic, user story, task, issue, wiki page). This distinguishes it from sibling tools like attachment_download and attachment_delete.
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 communicates that this tool is for uploading attachments to supported resources. It does not explicitly name alternatives or provide when-not-to-use guidance, but the context is clear enough that an agent would not confuse it with listing, downloading, or deleting attachments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It discloses a critical behavior: only the fields provided are changed (partial update). It also indicates it's a wrapper over issue_update, which gives context about its behavior. However, it doesn't mention return format, permission requirements, or error handling, which would be useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover the purpose, behavioral nuance, and relationship to issue_update without any fluff. It is extremely efficient 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?
The tool has 5 parameters, no output schema, and no annotations. The description covers the core semantics and the partial-update behavior, but lacks information about the return value, potential side effects, and validation. Given the tool's simplicity, it is reasonably complete but has notable 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 only 20% description coverage (only 'id' is described). The description lists the four settable fields (type, status, priority, severity) and ties them to the issue's properties, but doesn't explain their valid values or whether they are IDs. It adds some meaning but doesn't fully compensate for the schema's lack of detail.
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 sets an issue's type, status, priority, and severity in one call, and explicitly distinguishes it from issue_update as a convenience wrapper. This provides a specific verb, resource, and field list, making it easy to identify the tool's function among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names issue_update as the alternative and frames this tool as a convenience wrapper for common triage actions, implying when this specialized version should be used. However, it doesn't list explicit exclusion criteria or other alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate it's a non-read-only, idempotent, non-destructive operation. The description adds the partial-patch behavior and automatic version handling, which are meaningful behavioral traits not present in annotations. It does not contradict the 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 two sentences, front-loading the primary purpose and immediately adding the patch nuance and version warning. Every phrase carries information with no redundancy.
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 description covers the core update behavior, patch semantics, and a critical concurrency caveat. Since there's no output schema, it doesn't explain the return value, but the annotations provide safety context. Given the tool's moderate complexity, this is largely sufficient, though additional parameter clarification would improve completeness.
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 (only 3 of 11 parameters have descriptions). The description's partial-patch guidance adds a general semantic but does not explain individual parameters like type, status, or milestone, leaving ambiguity about expected value formats. This does not compensate sufficiently 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 states 'Update an existing issue' with a clear verb and resource, and the parenthetical 'partial patch' distinguishes it from issue_create and issue_delete. It clearly identifies the tool's function among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance to only include fields to change, establishing the tool's partial-patch usage pattern. It also explicitly warns not to pass the version field due to automatic handling, giving a concrete exclusion. However, it doesn't explicitly contrast with issue_create, though 'existing issue' implies 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?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read with open-ended return shape. The description adds minimal behavioral context beyond 'single membership by id' (which is mostly parameter usage). No additional side effects, error cases, or return constraints are disclosed, so a score of 3 is appropriate.
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 ('Get a single membership by id.') with zero wasted words. It is front-loaded and immediately actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-get tool with full schema coverage, read-only annotations, and no output schema, the description is complete. It clearly identifies the tool's purpose and provides enough context alongside the structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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%: 'id' is described as 'Resource id' and 'verbosity' has a detailed explanation of its enum values and default. The description itself adds no new parameter meaning, 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 ('Get') and resource ('single membership by id'), making the operation unambiguous. It clearly distinguishes this from membership_list (plural), membership_create/update/delete, and other membership-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this when you have a membership id and need exactly one membership. It does not explicitly name alternative tools (e.g., membership_list for all memberships), but the 'by id' phrasing gives clear context and no exclusions are needed given the simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the version field is handled automatically and that omitted fields remain unchanged, which are key behavioral traits beyond the annotations. Annotations already show readOnlyHint=false and idempotentHint=true, so the description adds context without contradicting them.
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 core action and immediately followed by the most important caveat. Every word earns its place and there is no fluff.
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 9-parameter mutation tool with no output schema and limited schema descriptions, the description covers the core behavioral nuance (partial patch, version handling) but omits return value expectations and per-field details. This leaves some gaps but is acceptable for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 44%, so the description partially compensates with the partial-patch rule that applies to all parameters. However, it does not elaborate on the meaning of several parameters like status, tags, or milestone, leaving some semantics to be inferred from names alone.
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 'Update an existing task' with a specific verb and resource, and adds partial patch semantics that distinguish it from task_create/delete. The sibling tools include task_create and task_delete, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit instructions on how to use the tool: 'only include the fields you want to change' and directs not to pass the version field. It does not explicitly mention alternatives (e.g., use task_create for new tasks) but the context is clear for an update operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds crucial behavioral context: 'This cannot be undone' and the two-step confirmation process. It also reveals that a preview is returned on the first call, which is non-obvious and valuable for the agent to know. This goes beyond what annotations provide.
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 three sentences: clear purpose, safety warning, and usage detail. It is front-loaded with the action, then states irreversibility, then explains the confirmation flow. No words are wasted; each sentence serves a distinct 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?
The description covers the deletion, irreversibility, and confirmation mechanism, which are essential. However, it leaves gaps: it does not explain the required resource parameter, and the 'preview returned by the first call' is vague without an output schema. These omissions prevent it from being fully complete for a 3-parameter 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 schema covers id and confirm well, but the resource parameter (required, enum) has no description in the schema, and the tool description does not clarify it. The description mentions 'by id' but omits the need to specify the parent resource type (epic, user_story, task, issue, wiki_page). This is a significant semantic gap, especially since resource is required, so the agent might not know to include 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 starts with 'Delete an attachment by id,' which is a specific verb+resource statement that clearly identifies the tool's function. It distinguishes itself from sibling tools like attachment_upload, attachment_list, and attachment_download by focusing on deletion, and from other delete tools by specifying attachment.
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 explains the confirmation protocol: 'elicitation-capable clients are prompted interactively; others must call again with confirm: true after reviewing the preview returned by the first call.' This gives clear operational usage guidance. However, it does not explicitly mention when to use this tool versus alternatives (e.g., if you need to remove a parent resource, use that resource's delete tool), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint=false, indicating a write operation. The description adds valuable behavioral context: each item is created independently, a bad item doesn't fail the others, and a structured per-item success/failure result is returned. This goes beyond the annotations and clarifies partial failure behavior, which is crucial for a batch 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 three sentences, each adding value: the core functionality, the independent failure behavior, and the return format. It is front-loaded with the most important information and contains no redundant phrases.
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 complexity of a batch operation with nested items, the description covers the key aspects: batch size, per-item independence, and result structure. It mentions the absence of native bulk-create capability, which helps explain why this tool exists. It lacks explicit mention of the required 'project' parameter, but with the schema and annotations, the overall context is sufficiently 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 0%, so the description must compensate. It clarifies the 'user_story' parameter's role ('each under its own parent user story') and the batch limit. However, it does not explain other parameters like project, subject, status, or assigned_to, leaving the schema names to carry the meaning. Partial compensation but not complete.
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: 'Create up to 20 tasks in one call, each under its own parent user story.' It uses the specific verb 'create' with the resource 'tasks', and the batch scope is explicit. It also distinguishes itself from the native Taiga bulk-create, which cannot carry per-item fields, making it unique among 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 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 creating multiple tasks with individual fields, and explicitly contrasts it with the native Taiga bulk-create. However, it does not explicitly mention using task_create for single-task creation, missing a clear alternative. The context is clear but exclusions are not fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds the useful detail that it 'goes through the same optimistic-concurrency path as a normal update,' which alerts the agent to potential concurrency failures, a dimension not covered by the 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?
Two sentences, both purposeful. The first states the action and target; the second provides a critical behavioral caveat. 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 mutation with 3 parameters, the description covers the action, target types, and a key behavioral detail. It omits any mention of the return value or error conditions, but the absence of an output schema makes this acceptable, and the annotation hints cover idempotency and destructiveness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only the 'id' parameter has a description). The description mentions the resource types (which duplicate the enum) and indicates 'comment' is the text being added, but it does not provide deeper semantics beyond what the schema already offers.
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 ('Add') and resource ('a comment to an epic, user story, task, or issue'). It clearly differentiates from sibling tools like comment_edit and comment_delete by establishing it is for creating a new comment.
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 clear context on which resources are valid (epic, user story, task, issue) but does not explicitly state when not to use or mention alternatives. The sibling list includes comment_edit and comment_delete, so the add vs. edit/delete distinction is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, but the description adds important behavioral details: the irreversible nature ('cannot be undone') and the confirmation requirement with specific client-dependent behavior (elicitation-capable vs. others). This goes beyond the annotation's simple destructive flag, explaining the exact interaction pattern. No contradiction with 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 two sentences: the first states the core action and irreversibility, the second explains the confirmation flow. Every word earns its place, with no redundant or vague statements. It is front-loaded and immediately informative.
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 destructive mutation tool with no output schema, the description covers the essential aspects: target scope, irreversibility, and the required two-call confirmation pattern. It mentions a 'preview' without detailing its format, but the absence of an output schema plus the explicit confirmation guidance makes the tool sufficiently usable for an agent to succeed.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 detailed descriptions for id, confirm, and comment_id, and the resource enum is self-explanatory. The description adds a little by mapping 'resource' to the four item types, but this is essentially redundant. With schema coverage at 75%, the description contributes some cross-reference but does not significantly enhance parameter 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 opens with 'Delete a comment from an epic, user story, task, or issue,' which clearly identifies the action (delete), the resource (comment), and the scope (four project item types). This directly distinguishes the tool from siblings like comment_add, comment_edit, and comment_list.
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 provides explicit usage context by explaining the two-step deletion process: first call without confirm returns a preview, then a second call with confirm:true (or interactive prompt) performs the deletion. While it does not explicitly name alternative tools to use instead, the confirmation guidance is a clear directive for when and how to invoke the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds that it includes field-change history entries as well as comments, and that the response is paginated as { items, pagination }. This is useful behavioral context beyond the 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 two sentences, front-loaded with the purpose, and includes a concise filter note and response shape. Every sentence earns its place with no redundancy.
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?
With no output schema, the description covers the response shape ('{ items, pagination }') and explains the entry types (comments + field changes). It could mention default page size or field details, but it is sufficient for a list tool with good schema annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 baseline is 3. The description adds no parameter-level detail beyond what the schema provides; the filtering hint relates to response data rather than 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 states 'List the comment history for an epic, user story, task, or issue' – a specific verb and resource scope. It distinguishes itself from comment_add/edit/delete and other list tools by focusing on comment history. The note about field-change history further clarifies what it returns.
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?
It clearly implies read-only use for retrieving comments/history and explains how to filter for comments only via non-empty 'comment' field. It does not explicitly name alternative tools or exclusions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety profile is known. The description adds useful behavioral context by detailing the response envelope ({ items, pagination }) and the pagination fields (count, current_page, has_next), plus the default page_size. No contradictions with 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 two sentences, front-loaded with the core action ('List epics'), and efficiently packs response shape, pagination details, and default page size without fluff.
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 read-only list tool with decent annotations and no output schema, the description adequately covers purpose, filtering, response structure, and pagination. It doesn't mention error cases or auth, but the straightforward nature and good annotations make this 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?
Schema coverage is 57%, moderate. The description mentions 'optionally filtered by the given query parameters' and gives the default page_size, adding some value. However, it doesn't clarify the semantics of undocumented params like q, status, or assigned_to, leaving gaps that the schema alone doesn't fill.
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 'List epics', a specific verb+resource pair that clearly distinguishes this from sibling tools like epic_get, epic_create, etc. It also mentions optional filtering and the response structure, making the purpose unmistakable.
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 states this lists epics with optional filters and provides a default page size, giving clear context for when to use it. It doesn't explicitly name alternatives (e.g., epic_get for a single epic), but the resource-oriented naming and sibling list make the usage context evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds value by stating the response shape '{ items, pagination }', which informs the agent about the returned structure and pagination. No contradiction with 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 extremely concise: two short sentences that state the action and response format. It is front-loaded with the primary purpose and contains no fluff 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?
For a simple read-only list operation with well-documented parameters and a clear response shape, the description is adequately complete. It covers the core function and returns an expected structure, though it does not mention potential edge cases like empty results or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 detailed descriptions for all parameters including 'id', 'page', 'page_size', and 'verbosity'. The description adds no extra parameter-level meaning beyond what the schema provides, so 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 a specific verb and resource: 'List the user stories linked to an epic.' This distinguishes it from siblings like epic_list (lists epics) and user_story_list (lists all user stories), and directly maps to the tool's name and title.
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 provides clear context for when to use this tool (to fetch user stories belonging to a particular epic), effectively differentiating it from alternatives such as epic_get or user_story_get. It does not explicitly name alternatives or exclusions, but the scope is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds that it returns live item counts and is cheaper than issue_list. This additional performance and data-freshness context goes beyond the annotations without contradicting them.
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, well-structured sentence that front-loads the action and lists the filter types succinctly. The comparative cost note at the end earns its place without bloating the text.
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-only tool with no output schema, the description conveys the purpose, return contents (filter values with live counts), and a practical cost consideration. It does not describe exact response formatting or error cases, but the provided information is sufficient for 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% coverage: the only parameter 'project' is described as 'Project id'. The description adds the tool-specific context of filtering issues but does not provide any new parameter-level details 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 uses a specific verb ('Get') and resource ('valid filter values for issues in a project'), clearly stating what the tool does. It also distinguishes itself from the related issue_list tool by noting it is cheaper for discovering ids, which separates it from that sibling.
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 provides a clear usage context: use this tool when you need filter values or ids cheaply, instead of issuing a full issue_list call. It does not explicitly mention alternatives like user_story_filters_data or when not to use, but the implication is strong enough for the simple scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses two important behavioral traits: the partial-patch semantics and the automatic handling of the optimistic-concurrency `version` field. These add significant context beyond what annotations (readOnlyHint, idempotentHint, etc.) already convey, and there is no contradiction with the 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 two concise sentences, immediately stating the primary purpose and then adding a crucial usage caveat. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with only three parameters and no output schema, the description covers the essential behavioral nuances (partial patch, version auto-handling). It does not mention potential permissions or side effects like audit logging for `is_admin`, but the schema already documents that, so the description is reasonably complete in 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 already provides descriptions for `id` and `is_admin`, covering 67% of parameters. The `role` parameter is left undocumented in both the schema and the description. The description adds no parameter-specific details, so it does not improve on the schema's already decent 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 identifies the tool's function: updating an existing membership. It explicitly states 'partial patch — only include the fields you want to change', which distinguishes this update operation from a full replacement or creation, and the title 'Update Project Member' reinforces the resource being acted upon.
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 appropriate use case (updating existing memberships) and provides a specific instruction about not passing the `version` field, which is valuable operational guidance. However, it does not explicitly mention when to use this tool over alternatives like `membership_create` or `membership_delete`, so it stops short of full exclusions or alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the response shape ({ items, pagination }) and the pagination fields (count, current_page, has_next), as well as the default page_size of 30. This adds useful behavioral context without contradicting the 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?
Two sentences, front-loaded with the primary purpose, then concise details on response format and default pagination. Every word earns its place without redundancy.
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 4 well-documented parameters and no output schema, the description provides the essential purpose, response structure, and pagination behavior. It is sufficiently complete to guide an agent in selecting and invoking the tool correctly, though it could mention edge cases or alternative tool references but not necessary given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented in the schema. The description only reiterates that filtering is optional and states the default page_size, which is already present in the schema. It adds no significant new meaning beyond the structured definitions.
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 'List milestones', a specific verb+resource action that clearly distinguishes it from sibling tools like milestone_get, milestone_create, and milestone_stats. The optional filtering phrase adds scope context.
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 indicates the tool is for listing milestones with optional query parameter filtering, giving clear context. It doesn't explicitly mention alternatives like milestone_get for single items, but the list-oriented purpose is evident from 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a non-destructive, idempotent write operation. The description adds valuable context: partial patch behavior and automatic handling of the optimistic-concurrency version field. This goes beyond the annotations without contradicting them.
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 deliver the essential purpose and key usage constraint. Every word earns its place, and the most critical information is 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 moderate complexity (5 params, no output schema), the description covers the core aspects: what it does, how to invoke it (patch), and a critical caveat about the version field. It doesn't discuss return values or error cases, but these are not essential for 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?
Schema description coverage is only 20% (only 'id' is described), so the description must compensate. It explains the patch semantics generally but doesn't elaborate on each field (e.g., date format, behavior of 'closed'). The property names are self-explanatory, but more detail would improve 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 uses a specific verb ('Update') and resource ('existing milestone'), clearly distinguishing it from milestone_create or milestone_delete. It also clarifies the partial patch nature, so the agent knows it modifies rather than replaces.
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 states the patch semantics ('only include fields you want to change') and warns against passing the version field. While it doesn't explicitly mention when to prefer this over create/delete, the context of an existing milestone makes usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context by stating the operation is lightweight ('without fetching full details') and returning exactly the type and numeric id. It does not contradict the read-only annotation, though it omits edge-case behavior like invalid ref handling.
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, well-structured sentence that front-loads the core action and result format. It contains zero filler and every word adds value, making it highly concise and clear.
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 read-only resolution tool with no output schema, the description sufficiently covers key aspects: input (ref, project), output (type and numeric id), and the lightweight nature. It lacks details on error handling or response shape beyond type/id, but given the low complexity and good annotations, 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 already provides 100% coverage with descriptions for both `ref` and `project`. The description reinforces that the ref is project-scoped but does not add significant semantic detail beyond what the schema already documents, 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 tool resolves a project-scoped ref to its type and numeric id, using the specific verb 'Resolve' and naming the resource ('a project-scoped ref'). It distinguishes this tool from siblings by explicitly contrasting it with fetching full details, so 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: whenever you have a ref like #436 and need only its type and id without full details. It does not explicitly name alternative tools (e.g., issue_get, user_story_get) or state when not to use it, but the lightweight intent is evident.
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 labels the tool as a 'raw request' escape hatch, which implies arbitrary HTTP methods and side effects, but it does not explicitly warn about potential destructive outcomes (e.g., DELETE permanently removing data) or authentication/rate-limit nuances. With only openWorldHint=true annotation, the description adds some context but leaves room for the agent to infer safety 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 is two sentences long and front-loads the critical 'escape hatch' concept. The first sentence uses a colon to immediately define the tool's purpose, and the second sentence provides a crisp usage rule. Every word earns its place, with no redundant 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?
Given the tool's nature as a raw HTTP request wrapper, the description sufficiently covers its purpose, scope, and relationship to dedicated tools. It does not explain response formats or error handling, but for an escape-hatch tool, the raw response is inherently unpredictable and the schema already addresses common pitfalls (OCC version, body serialization). The description plus schema together provide adequate context for an agent to select and invoke this 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 tool-level description does not describe parameters; however, the input schema provides rich descriptions for method, path, and body, including OCC version requirements and JSON formatting pitfalls. With 75% schema coverage, the schema carries most of the parameter semantics, so the description adds no additional value 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 opens with 'Escape hatch: make a raw request to any /api/v1/ endpoint on the configured Taiga instance', which is a specific verb+resource combination. It distinguishes from siblings by explicitly stating it covers functionality not provided by dedicated tools, and points to examples like importers, webhooks, and application tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use this tool ('for functionality not covered by a dedicated tool') and when not to ('Prefer a dedicated tool when one exists'). It also gives example domains (importers, webhooks, application tokens) that illustrate the intended use cases, making the alternative selection explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint and readOnlyHint false; the description adds irreversibility ('cannot be undone') and the preview/confirmation behavior, which is valuable beyond 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?
Two concise sentences with no redundant information, front-loaded with the core 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?
Adequately covers purpose, confirmation flow, and irreversibility for a simple two-parameter tool. The absence of an output schema is acceptable since the tool likely returns nothing meaningful.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 covers both parameters fully (100% coverage), including the confirm behavior. The description adds little beyond schema, so the 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 action ('Delete a task by id'), identifying the verb and resource, and distinguishes from sibling task tools like task_update or task_get.
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 explains the two-call confirmation workflow: first call without confirm returns a preview, then call with confirm: true. It doesn't compare against alternative deletion tools, but the context of CRUD siblings makes the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds 'live item count', indicating real-time counts, and a performance note about being cheaper, which goes beyond the structured annotations and gives useful 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 that front-loads the action ('Get the valid filter values'), lists the categories, and adds a cost-benefit rationale. Every phrase earns its place, with no redundancy or fluff.
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 one-parameter, read-only tool with no output schema, the description sufficiently explains what the response contains (valid filter values with live counts) and when to use it. It could optionally mention how these values feed into task_list filtering, but the core usage 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?
The schema has 100% coverage for the only parameter 'project' with a description 'Project id'. The description does not add further parameter details, but the baseline of 3 applies because the schema fully documents the parameter and the description's mention of 'in a project' aligns with 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 starts with 'Get the valid filter values' and lists statuses, tags, assigned users, and roles, clearly identifying the resource (tasks in a project). It also distinguishes itself from the sibling task_list by noting it is 'cheaper than a full task_list call just to discover ids'.
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 frames the tool as a cheaper alternative to task_list for discovering valid filter IDs, giving clear context on when to use it over that sibling. It does not explicitly mention other alternatives like user_story_filters_data, but the task-specific scope is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds critical behavioral details beyond the annotations: it reveals that items are created independently (a bad item doesn't fail the batch) and that the return is a structured per-item success/failure result. These are not encoded in the readOnly/destructive/idempotent hints and significantly aid agent understanding.
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 three concise sentences, each serving a clear purpose: the first announces the action, the second explains the independence behavior, and the third describes the return format and contrasts with an alternative. It's front-loaded and free of extraneous detail.
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 complexity of a batch endpoint with nested items, the description covers the essential limits (up to 20), per-item independence, and return structure. The schema provides the required field details, so the description needn't repeat them. However, it could have mentioned the required fields or given an example, but the structured schema fills that 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?
The tool description provides almost no parameter-level guidance. It mentions the 20-issue limit but doesn't explain the `project` parameter or the required fields (`subject`, `type`, `priority`, `severity`) within `items`. Since schema coverage is 0%, the description fails to compensate for the lack of schema descriptions.
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 resource ('up to 20 issues'), making it obvious this is a batch creation tool. The mention of per-item fields distinguishes it from native Taiga bulk-create and implies differentiation from single-issue creation.
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 contrasts this tool with the native Taiga bulk-create, explaining when this tool is preferable (when per-item fields are needed). However, it doesn't mention when to use this over single-issue creation or other batch tools, though the tool name and sibling context imply the use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently discloses independent item creation, partial failure behavior, and the return structure ('per-item success/failure'), which are not revealed by annotations. This is valuable behavioral context beyond the readOnly/destructive hints and matches the openWorldHint annotation without contradiction.
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 long, front-loads the core action, and every clause earns its place. It conveys the limit, independence, return type, and technical rationale without redundancy or fluff.
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 description covers essential operational details: the 20-item limit, per-item independence, and the return format. However, with no output schema present, it could be more explicit about the exact structure of per-item results (e.g., error codes, IDs). For a batch tool, this is adequate but not exhaustive.
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 provides zero parameter-level detail; schema description coverage is 0%. It does not explain what 'project' or 'items' mean beyond the schema's property names and types, nor does it clarify subtleties like points role mapping or the required subject field. Given 0% coverage, the description should compensate but fails to add meaning to 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 clearly states the verb 'Create', the resource 'user stories', and a specific limit ('up to 20'), making the tool's purpose immediately obvious. It also implicitly distinguishes itself from sibling batch tools like batch_create_issues and batch_create_tasks by naming the user story 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?
The description provides clear context for when to use this tool: when creating multiple user stories at once and needing per-item field support. It explicitly contrasts with native Taiga bulk-create, which lacks per-item fields. However, it does not explicitly mention alternatives like using user_story_create for single creations or compare to batch_create_issues/tasks, though the context is still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by revealing a non-obvious side effect: the epic is created via API but remains invisible in the Taiga web UI when the Epics module is disabled, with links 404ing. This adds crucial behavioral context that annotations (readOnlyHint=false, destructiveHint=false) do not cover. The remediation hint (use project_update) is also transparent.
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 sentences that front-load the primary purpose ('Create a new epic') and then deliver the essential caveat about module visibility. Every word earns its place; there is no redundant 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?
Given the tool's complexity (9 params, no output schema), the description covers the most important non-obvious operational detail (module invisibility) and provides a remedial action. However, it does not explain the return value or the details of optional parameters, and the parameter semantics are thinly covered. Still, for a creation tool with required fields in the schema, it is reasonably complete.
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 22%, and the description itself mentions no parameter details beyond the implicit 'project' in the module enablement context. Parameters like tags, color, status, milestone, assigned_to, and description are left completely unexplained, so an agent gets little semantic guidance about their values oreffects.
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 'Create a new epic,' a clear verb+resource combination that precisely identifies the tool's function. It distinguishes itself from sibling epic_list, epic_get, epic_update, and epic_delete tools by focusing on creation. The added caveat about module visibility further specifies the creation behavior.
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 indicates when to use this tool: to create a new epic. It also provides conditional alternative guidance: if the Epics module isn't enabled, use project_update to enable it. However, it does not explicitly differentiate from epic_update for modifications or other epic-related tools, relying on the tool name for that distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating no side effects. The description adds value by disclosing the response structure (grouped items and pagination), which is not in annotations. It does not contradict annotations and provides useful behavioral context beyond the safety profile.
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 three short sentences with front-loaded purpose. Every sentence contributes: scope, resource coverage, and return format. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity, the description fully covers what the agent needs: search scope, target entities, and exact response shape. No output schema exists, so the explicit return format description fills that gap. Annotations cover safety, making this 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%: both 'text' and 'project' have descriptions in the input schema. The tool description reinforces that 'project' scopes the search, but does not add significant extra meaning beyond the schema. Baseline 3 is appropriate since 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 a specific verb ('text search') with a defined scope ('project-scoped') and enumerates the resource types searched (epics, user stories, tasks, issues, wiki pages). It also describes the output structure (grouped by type), making the tool's purpose unambiguous and distinct from sibling tools like ref_resolve or entity-specific getters.
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 usage context: it is for searching across multiple entity types within a project. It does not explicitly name alternatives or exclusions, but no other sibling tool provides similar cross-type full-text search, so the intended use is clear. Lacks explicit 'when not to use' guidance, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds behavioral context: 'each with a live item count' clarifies the openWorldHint (results are dynamic) and informs the agent that counts reflect current data. It also lists the exact categories returned. However, it does not disclose response format or potential errors, but for a read-only lookups this is sufficient.
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, information-dense sentence that leads with the action ('Get the valid filter values') and immediately enumerates the specific filter types. It includes a cost-benefit comparison without any wasted words, making it both concise and effectively structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description covers the essential return contents (filter values and live counts), the target resource (user stories), and the practical context (cheaper alternative for IDs). Combined with strong annotations (readOnly, openWorld), this provides a complete picture for a simple, single-parameter lookup 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 already fully documents the single 'project' parameter with 'Project id'. The description only rephrases this as 'in a project' without adding syntax, format, or additional meaning. With 100% schema coverage, the baseline score of 3 is appropriate—the description neither improves nor detracts from 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 clearly states the tool's function: 'Get the valid filter values (statuses, tags, assigned users, epics, roles) for user stories in a project', with a specific verb ('Get') and resource ('user stories'). It also distinguishes itself from the sibling user_story_list by explaining its unique purpose—discovering filter ids with counts rather than retrieving full 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?
The description provides a direct usage cue: 'cheaper than a full user_story_list call just to discover ids', indicating when to prefer this tool over the closest alternative. It implies a use case (needing filter options with counts) but does not explicitly discuss when not to use it or mention other sibling filter tools (task_filters_data, issue_filters_data), which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations by disclosing that deletion is irreversible ('cannot be undone'), that a preview is returned on the first call, and that confirmation is required via one of two distinct mechanisms. This provides substantial behavioral context not present in the annotations or schema.
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, consisting of two sentences that front-load the core function and then provide essential safety/confirmation details. No filler or redundant content.
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 description thoroughly explains the confirmation workflow, which is the most complex aspect of this destructive tool. However, it does not disclose potential side effects on related entities (e.g., linked user stories) or specify the content of the preview. Given the annotations and complete schema, this is a minor gap rather than a fatal omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 both parameters (id and confirm) with 100% coverage. The description reinforces the role of confirm but does not add new parameter-level meaning beyond what the schema already provides; it mentions the preview returned by the first call, but the schema already notes that confirm is ignored for elicitation-capable clients.
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 'Delete a epic by id', clearly stating the action (delete) and the resource (epic), and explicitly identifies the identifier mechanism. The admonition 'This cannot be undone' reinforces the destructive nature and distinguishes it from non-destructive epic operations like update.
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 explains when and how to use the tool, detailing the mandatory confirmation flow: elicitation-capable clients are prompted interactively, while others must make a second call with 'confirm: true' after reviewing the preview. It does not explicitly mention alternatives (e.g., epic_update), but the confirmation guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the optimistic-concurrency version field is handled automatically, a behavioral nuance not covered by the annotations. It also clarifies partial patch semantics, ensuring omitted fields remain unchanged. These details add value beyond the annotations (readOnlyHint=false, idempotentHint=true), though it doesn't describe response formats or error cases.
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 verb+resource, and every sentence earns its place. The partial patch guideline and version note are essential, and there is no wasted or redundant wording.
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 has 9 parameters and no output schema, the description provides adequate context for an update operation: it explains the patch semantics and the auto-handled version field. It could have mentioned expected return values or error conditions, but the annotations and partial patch description cover the essential behavioral aspects well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 33%, the description compensates by explaining the overall patch behavior: only include fields to change. This gives semantic meaning to all optional parameters without listing each one. It also adds the negative instruction about the version field, which is helpful. However, it doesn't detail individual parameter formats beyond what the schema already provides for watchers and assigned_to.
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 'Update an existing epic', a specific verb + resource that clearly states the tool's function. It immediately distinguishes itself from sibling tools like epic_create and epic_delete by focusing on updating an existing object.
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 specifies 'partial patch — only include the fields you want to change', giving clear guidance on how to use the parameters. It also instructs the user not to pass the version field. However, it does not explicitly name alternatives like epic_create for new epics, so it falls short of a 5 for explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the exact response structure ({ items, pagination } with count, current_page, has_next), the default page_size (30), and hints at the cost of pagination by suggesting filters. It also notes the pagination data is 'read from Taiga,' grounding the behavior. No contradictions with 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 three sentences, each earning its keep: purpose, response schema/defaults, and a cost-saving tip. It is front-loaded with the core action and avoids redundancy, making it efficient and scannable.
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 list tool with 10 parameters and no output schema, the description provides the response envelope, default page size, and strategic usage advice. It does not walk through every parameter, but the schema already covers key ones (page, page_size, verbosity, project). The description is sufficiently complete for typical use, though it could clarify how filters combine or mention q.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description has a burden to explain parameters. It mentions that the tool is 'optionally filtered' and that type/status/priority/severity/tags/assigned_to ids can be discovered via issue_filters_data, adding meaning for those previously undocumented params. However, it does not explain the `q` parameter or specific semantics of each filter beyond their names, leaving some 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 opens with 'List issues, optionally filtered by the given query parameters,' which clearly states the verb (list) and resource (issues) and differentiates from sibling tool issue_get by implying list semantics. It also distinguishes from issue_filters_data by recommending that tool for discovering valid ids, making the purpose distinct.
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 directs users to use issue_filters_data to discover valid filter ids 'cheaply' instead of paging through results, providing an when-to-use alternative. It also implies the tool is for listing with optional filters, but does not explicitly state when not to use it (e.g., for a single issue) or contrast with other list siblings like task_list, though names make this obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavioral trait beyond the annotations: it sends real invitation emails for entries that don't match existing users, implying that existing users are added directly without email. This adds valuable context beyond readOnlyHint=false and openWorldHint=true, which alone do not specify the email side effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and immediately adding the critical email caveat. Every word earns its place; there is no filler or redundancy.
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 bulk operation with nested objects and notable side effects, the description covers the main purpose, per-entry requirements, and the email behavior. It does not mention partial failure handling or return values, but given the absence of an output schema and the existing annotations, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining that each entry needs a role_id and either a username or an email. It clarifies the either/or relationship and hints at the side effect of email sending, which goes beyond the raw schema properties despite not detailing every field.
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 ('invite') and clearly identifies the resource (project members) and the bulk scope. It distinguishes from sibling tools like membership_create by emphasizing 'multiple members' and 'in one call', making its purpose unmistakable.
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 when to use the tool: when you need to invite multiple members in a single operation. It does not explicitly name alternatives or exclusions, but the bulk context is unambiguous and effectively differentiates it from the single-membership tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint: true, idempotentHint: false), the description discloses irreversibility ('cannot be undone') and the two-step confirmation behavior, including the preview return and the differential handling for elicitation clients. This adds significant behavioral context that annotations alone do not provide, and it does not contradict the 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 concise: three short sentences, front-loaded with the purpose, and each sentence adds critical information (purpose, irreversibility, confirmation process). 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?
With only two parameters, no output schema, and rich annotations, the description covers the essential aspects: what it does, that it's destructive, and the confirmation workflow. It does not describe error cases or return values, but these are not required given the tool's simplicity. The openWorldHint suggests possible external side effects, but the description still provides sufficient 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 already provides 100% coverage for both parameters, with a detailed description for confirm. The tool description mentions 'confirm: true' and 'preview' but does not add new meaning beyond the schema. Since the schema carries the parameter documentation, 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 milestone by id'), specifying the verb and resource, and distinguishes it from sibling milestone tools (list, get, create, update, stats) by its destructive action. It also adds clarity by noting irreversibility and confirmation, which further differentiates it as a delete operation.
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 provides clear usage context by explaining the confirmation workflow: elicitation-capable clients get an interactive prompt, while others must first call without confirm to receive a preview, then call again with confirm: true. This is explicit how-to guidance. However, it does not explicitly state when not to use the tool or mention alternatives (e.g., updating instead of deleting), but the context is sufficient for a delete operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds valuable context about automatic handling of Taiga's optimistic-concurrency version field and instructs not to pass it, which goes beyond annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose and key behavioral instruction. The second sentence is a crucial warning about the version field. 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 9-parameter update tool, the description covers the critical partial-patch behavior and version handling. It doesn't spell out return values or permissions, but given no output schema and reasonable sibling context, it's sufficiently complete.
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 description coverage is 67%, so the schema does much of the work. The description adds essential semantics: only include fields to change (partial patch) and avoid passing version, which is not in the schema. This compensates for lack of parameter descriptions on name, description, and is_private.
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 'Update an existing project' with a specific verb and resource, and further explains it's a partial patch. This distinguishes it from sibling tools like project_create, project_delete, and project_get.
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 this tool is used when modifying only select fields of an existing project, thanks to the 'partial patch' instruction. It doesn't explicitly name alternatives or exclusions, but the context and sibling tool names make usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the description adds value by disclosing the response envelope ({ items, pagination }), pagination fields, and default page_size. It does not overpromise beyond the read-only nature, so no contradiction.
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?
Three sentences, front-loaded with the core purpose, and every sentence adds value: response shape, pagination details, default page_size, and alternative tool guidance. No filler or redundancy.
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?
Without an output schema, the description provides the response structure and pagination semantics, which is important. It also covers a key usage pattern (discovering filter ids cheaply). However, it does not specify required parameters or behavior when filters are omitted beyond what the schema shows, so slight gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, so the schema carries most parameter meaning. The description adds general context about filtering and points to task_filters_data for valid ids, which is useful, but it does not detail each undocumented parameter (status, milestone, user_story). This is adequate but not exceptional.
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 'List tasks' with optional filtering by query parameters. It distinguishes itself from sibling tools like task_get by focusing on listing rather than single retrieval, and further differentiates by pointing to task_filters_data for filter discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides an alternative: 'Use task_filters_data to discover valid status/tags/assigned_to ids cheaply instead of paging through results.' This tells the agent when to use a lighter-weight sibling instead of task_list, and implies task_list is for actual list retrieval, not filter metadata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations by disclosing irreversibility ('This cannot be undone') and the confirmation workflow (interactive prompt for elicitation-capable clients, confirm:true for others). This is exactly the kind of behavioral context that helps an agent handle a destructive operation safely.
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 compact and front-loaded. The first sentence states the essential action, the second emphasizes irreversibility, and the third details the confirmation flow. Every sentence contributes necessary information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, irreversibility, confirmation, and the preview from the first call. It does not specify the exact response format (no output schema exists), but for a delete tool with two-step confirmation, the key behavior and prerequisites are well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 both parameters, so the schema already explains 'id' and 'confirm' thoroughly. The description mentions confirmation behavior but does not add significant new parameter-level semantics 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 clearly states 'Delete a user_story by id', using a specific verb and resource. It distinguishes this tool from siblings like user_story_update and user_story_get, and the two-step confirmation behavior is immediately tied to the delete 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 explains when to use the tool (to delete a user_story) and provides important usage context (requires confirmation, cannot be undone). It does not explicitly compare to alternatives, but the tool's role is unambiguous given the sibling list and the single-purpose delete action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description adds critical behavioral context: the operation is irreversible and requires a two-step confirmation flow for non-elicitation clients. It also explains how the confirm parameter behaves differently depending on client capabilities, which is not evident from annotations alone.
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 packs the irreversibility and confirmation details efficiently. Every sentence earns its place; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 params, no output schema) and strong annotations, the description covers all essential aspects: the require confirm behavior, the preview-based deletion, and the interactive alternative. It is complete for a delete 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 has 100% description coverage, so the baseline is 3. The tool description's mention of confirm:true and previews largely mirrors the schema's own parameter description, adding little new semantic value beyond what is already structured.
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 'Delete a issue by id,' a specific verb and resource that clearly distinguishes it from sibling tools like issue_update or issue_get. Despite the minor grammar issue, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on the confirmation workflow: elicitation-capable clients get interactive prompts, while others must call again with confirm:true after reviewing the preview. It doesn't explicitly mention when to prefer issue_update over delete, but the confirmation context is strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true), the description adds critical behavioral details: the operation cannot be undone, and it requires a confirmation step—either interactive prompting or a second call with confirm:true after reviewing a preview. This explains the mechanism and irreversibility, adding significant value beyond the structured 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 two sentences long, with the primary action front-loaded and essential caveats (irreversibility, confirmation flow) following in a compact, structured manner. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive delete operation, the description fully covers the action, irreversibility, and the two-step confirmation process. With no output schema and simple parameters, there are no significant information 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 already provides thorough descriptions for both parameters (id and confirm), including the confirmation behavior. The description repeats this but adds no new parameter-level detail, so the 100% schema coverage carries the semantic load, matching the baseline score.
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 membership by id.' This uses a specific verb and resource, distinguishing it from membership_get, membership_update, and other membership operations. The title reinforces the purpose.
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 provides clear context for use: to delete a membership by id, with a confirmation workflow that must be followed. It doesn't explicitly compare to alternatives or state when not to use it, but the action and resource are unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false) and non-idempotent behavior. The description adds valuable context beyond annotations: that it specifically targets 'pending' invitations and sends an email. It does not explain error conditions or side effects of repeated sends, but the annotation about idempotency covers that.
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 waste. It states the action and the target in eleven words, earning a perfect score for efficiency and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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, no output schema, and annotations covering safety and idempotency, the description is complete. It tells the agent what the tool does (resends an email), the precondition (pending invitation), and the resource type. No further detail is needed for effective use.
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% with 'id' described as 'Membership id'. The description enriches this by clarifying that the id refers to a pending project invitation, giving the parameter its operational context. This goes beyond the bare schema definition.
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 'resend' and identifies the resource as 'pending project invitation email', clearly distinguishing it from other membership actions like create, update, or delete. This makes the tool's purpose unambiguous and differentiates it 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this when a pending project invitation email needs to be resent. However, it does not explicitly mention when not to use it or point to alternative tools, which would push it to a 5. For such a simple operation, the implied usage is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, idempotentHint=false), the description clearly states that deletion cannot be undone and explains the two-call preview/confirm process. This provides crucial context for safe use.
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?
Three short sentences lead with the core purpose, then add critical warnings and confirmation details. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation, the description covers purpose, irreversibility, and the confirmation protocol. Parameters are fully documented in the schema, and no output schema is needed for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions for both parameters are already detailed, including the confirm behavior for elicitation-capable clients. The description adds no new parameter-specific information beyond what the schema states, 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 opens with 'Delete a wiki_page by id,' clearly identifying the verb and resource, and distinguishing it from wiki_page_update, create, or get. The irreversibility warning reinforces the destructive purpose.
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?
It explicitly outlines the confirmation flow: elicitation-capable clients are prompted interactively, while others must call again with confirm:true after reviewing the preview. It does not explicitly name alternatives, but the delete use case is unambiguous given 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details beyond the annotations: the tool performs a partial patch (not a full replacement), and the optimistic-concurrency version field is handled automatically, with a warning not to pass it. These are not conveyed by the annotations (readOnlyHint=false, idempotentHint=true) and add significant context for correct invocation.
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, front-loaded with the action and primary semantics. Every sentence provides value: the first states what it does and the patch nature, the second handles a critical concurrency caveat. 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 update tool, the description covers purpose, usage, and a key behavioral nuance (version handling). It does not mention return values, but no output schema exists and the operation's result is relatively predictable. It is arguably complete for the complexity level, though a brief note on the response could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 33% (only 'id' has a description), the description adds essential meaning by explaining that only included fields are changed, which directly informs usage of 'slug' and 'content'. It also warns against passing the 'version' parameter, which is not in the schema. This compensates for the low schema coverage, though it does not elaborate on the individual parameters beyond the patch concept.
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 an existing wiki_page') and specifies 'partial patch' semantics, distinguishing it from create/delete/get operations. The verb and resource are explicit, and the partial-patch qualification adds precision.
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 usage guidance: it is for updating existing wiki pages, and it explains the partial-patch pattern ('only include the fields you want to change'). It also instructs not to pass the version field. It does not explicitly compare to alternatives like wiki_page_create or wiki_page_delete, but the update context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive behavior, but the description adds crucial context: the action is irreversible ('cannot be undone') and requires a confirmation step, which is not evident from annotations alone. It clearly explains the interactive vs. confirm: true flow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action and irreversibility, followed by a concise explanation of the confirmation behavior. Every word earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains the expected flow: a first call returns a preview, and a second call with confirm: true completes deletion (unless interactively prompted). This covers the necessary context for a destructive operation, and the sibling list shows clear placement among project 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 already provides 100% coverage of both parameters (id and confirm) with detailed descriptions, including the confirmation semantics. The tool description reiterates this but adds little new parameter-level 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 clearly states the action ('Delete a project by id') and distinguishes it from sibling tools like project_update or project_list. It specifies the resource type and the method, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: deletion requires confirmation, with a two-step process for non-interactive clients (first call preview, second call confirm: true) and automatic interactive prompting for elicitation-capable clients. This effectively tells the agent when and how to use the tool, and the confirmation alternative.
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-server MCP server](https://glama.ai/mcp/servers/madebyclowd/taiga-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/madebyclowd/taiga-mcp-server)

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/madebyclowd/taiga-mcp-server'

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