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

With no annotations, the description carries the disclosure burden and does well: it states the owner-only authorization requirement and summarizes the returned fields. It does not explicitly say the operation is read-only, but 'stats' strongly implies non-mutation and there is no destructive behavior to disclose.

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

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

Two short sentences with no filler. The core resource and metrics are front-loaded, and the access restriction follows immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only stats tool with one optional parameter and no output schema, the description is complete: it explains the metrics returned, the per-token grouping, and the authorization prerequisite. The schema handles the look-back window.

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

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

There is only one optional parameter (`days`), and the schema already documents it at 100% coverage: 'Look-back window in days; omit or 0 for all time.' The description adds no parameter detail 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.

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

The description names the exact resource (MCP usage stats) and enumerates the metrics returned: total calls, denials, top tools, and first/last seen. This is specific enough to distinguish it from the Taiga project-management siblings, none of which overlap with usage statistics.

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

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

The description implies the tool is for inspecting per-token usage and supplies a key prerequisite: 'Owner (full token) only.' However, it does not explicitly say when to use this versus other approaches, nor does it state exclusions or alternatives beyond the access restriction.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it says nothing about notification side effects, permissions, comment formatting, or what is returned. For a mutation tool with zero structured safety metadata, this is a meaningful gap.

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

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

A single efficient sentence with no waste, but the brevity reflects under-specification rather than discipline—nothing is front-loaded beyond the action itself.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A mutation tool with no annotations, no output schema, and 0% parameter coverage needs substantially more: permissions, format, and return expectations are all absent. What is present is barely enough to invoke the call correctly.

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

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

Schema description coverage is 0%, so the description must compensate and does not: 'object_id' is never explained (the id of the story/task/issue/epic), and the 'comment' field's format (plain text vs markdown) is unspecified. The enumeration of object types only restates the enum already in the schema.

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

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

States a specific verb ('Add a comment') and the exact resource targets ('userstory, task, issue, or epic'). There is no other comment-related sibling, so differentiation is mostly a non-issue, though it does not clarify relationship to update tools like taiga_update_user_story.

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

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

No indication of when to use this versus editing the object's description, no prerequisites such as project membership or permissions, and no mention of whether comments support markdown. The agent gets only the bare action.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that existing Taiga users are added while unknown emails receive an invitation, but it omits permissions/auth requirements, duplicate-member handling, failure behavior, and 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.

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

Two tight sentences front-load the core action and then add the important existing-vs-unknown behavioral distinction. No sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a three-parameter mutation tool with no annotations and no output schema, the description covers the main invite behavior but leaves out permission requirements, duplicate handling, and what happens on success/failure. It is minimally sufficient to call the tool but not complete.

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

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

Schema description coverage is only 33%, and the description partially compensates by clarifying that email identifies the user and role_name accepts values like 'Product Owner' or 'Back'. However, project_id is not semantically explained beyond being implied by 'to a project', and email format remains undocumented.

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

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

The description uses a specific verb and resource: inviting a user to a project by email with a role. It clearly distinguishes the operation from project/story/issue CRUD siblings, though it does not explicitly name a sibling since none directly overlaps.

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

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

Usage is implied by 'Invite a user to a project', but the description gives no explicit when-to-use vs when-not guidance, no alternatives, and no prerequisites. The operation is simple enough that implied usage is minimally adequate.

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

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

With no annotations, the description carries the full burden. It usefully discloses the required item shape and the epic_id prerequisite, but for a bulk mutation tool it omits behavior that matters most: atomicity/partial-failure semantics, whether epic linkage is required or optional, and what happens if one story in the batch is invalid.

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

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

Two sentences, zero filler, with the per-story requirement and the blocking epic_id caveat both front-loaded. Efficient, though the capitalized warning eats space that could have covered failure behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Placeholder.

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

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

Schema coverage is only 25%, and the description does add real meaning beyond the schema: the required inner 'subject', the optional 'description' and 'tags', and the numeric-vs-ref caveat on epic_id. However, sprint_id and project_id are undocumented in both schema and description, leaving a genuine compensation gap.

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

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

States a specific verb and resource ('Create multiple user stories') and the required per-item field ('subject'), so it is distinguishable from taiga_create_user_story by the 'multiple' framing. It never explicitly contrasts with the single-create sibling, so it stops short of a 5.

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

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

Gives a concrete prerequisite workflow for one parameter: call taiga_list_epics first to obtain epic_id, and warns against using ref #. It says nothing about when to choose bulk creation over calling taiga_create_user_story repeatedly, nor when to supply sprint_id.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about required permissions, default field values, whether project_id must reference an existing project, or what the created epic returns. For a mutation tool this is a significant gap.

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

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

A single front-loaded sentence with no filler; the purpose is stated immediately and nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A mutation tool with no annotations, no output schema, and low parameter coverage would need the description to supply creation semantics, prerequisites, and side effects. It supplies none of these.

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

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

Six parameters with only 17% schema description coverage (only 'color' is documented). The description adds no meaning for project_id, subject, description, tags, or assigned_to, so the agent must guess formats and semantics for most inputs.

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

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

States a specific verb ('Create') and resource ('epic') and explains its role: grouping related user stories under a high-level goal. It doesn't differentiate from siblings like taiga_create_user_story or taiga_bulk_create_stories, but the resource is distinct enough to be unambiguous.

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

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

The phrase 'to group related user stories' implies when an epic is appropriate rather than a story, but there is no explicit when-to-use/when-not guidance nor any mention of alternatives such as taiga_link_story_to_epic or taiga_update_epic.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about permissions needed, defaults applied to unspecified fields, whether the created issue is returned, or the fact that project_id and subject are mandatory. It only implies the tool is a mutation by the word "Create".

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

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

A single short sentence with no filler and the operation front-loaded, but its brevity comes at the cost of under-specification rather than efficiency. Nothing is wasted, but much is missing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter mutation tool with no annotations and no output schema, the description is far too thin to let an agent call it correctly without opening and interpreting the raw schema. It should at minimum name the required fields and describe accepted values for the enumerated-looking fields.

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

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

Schema description coverage is 0% across 8 parameters, and the description only name-drops three optional fields (type, priority, severity) without explaining accepted values, defaults, or formats. It never mentions the two required parameters, project_id and subject, nor tags, assigned_to, or description.

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

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

The description names a specific verb and resource ("Create an issue") and lists three of the fields it sets, so the core operation is unmistakable. It does not distinguish itself from siblings such as taiga_create_user_story or taiga_create_task beyond the word "issue", leaving the agent to rely on the tool name for that separation.

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

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

There is no guidance on when to create an issue versus a user story, task, or epic, nor any mention of prerequisites like project membership or the required project_id. The agent must infer context entirely from the tool name.

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

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

With no annotations, the description must carry the behavioral load. It usefully discloses that ownership is fixed to the connected account (no owner parameter exists) and that the response includes id and slug, but it says nothing about permissions required, privacy defaults, failure modes, or whether creation is reversible.

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

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

Two short, front-loaded sentences with no filler: purpose first, then the ownership constraint and return values. Nothing could be removed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations and no output schema, it covers purpose and returns, but leaves the agent guessing about permissions, privacy behavior, and the semantics of two of three parameters. Adequate but with clear gaps.

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

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

Schema description coverage is only 33% (just is_private's default). The description does not explain what 'name' means, whether it must be unique, or what 'description' controls, so it fails to compensate for the undocumented parameters.

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

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

States a specific verb and resource ('Create a new Taiga project') and adds a scope qualifier (owned by the connected account), which distinguishes it from list/get project siblings by implication. It stops short of naming alternatives explicitly, so it is clear but not fully differentiated.

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

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

The name and description imply when to use it (to create a project), but there is no guidance on when not to use it, prerequisites, or which sibling to choose if a project already exists. The parenthetical ownership note is a constraint, not usage guidance.

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

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

With no annotations, the description carries the full behavioral burden. It mentions date formatting, but does not disclose permissions, side effects, whether the project must exist, or what happens on success/failure.

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

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

Two short sentences, front-loaded with the action and followed by the only stated format constraint. There is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a four-required-parameter mutation tool with no annotations, no output schema, and zero schema descriptions, the definition is too thin. Important context about project_id, permissions, and return behavior is missing.

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

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

Schema description coverage is 0%, and four parameters are required. The description adds only date format guidance for start_date/end_date, leaving project_id and the relationship to name unexplained.

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

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

The description states a specific verb and resource: 'Create a new sprint.' It is clearly a create operation, distinguishable from sibling list/get tools, though it does not explicitly name alternatives or siblings.

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

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

It offers no explicit when-to-use guidance, prerequisites, or alternatives. The intended use is implied by the verb 'Create,' but there is no routing context for choosing this tool over others.

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

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

No annotations are provided, so the description carries the full behavioral burden. It mentions optional linkage to a user story or sprint but does not disclose permissions, side effects, default values, or what is returned after creation, which is a significant gap for a mutation tool.

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

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

The description is front-loaded with the core action and contains no filler. However, for a six-parameter creation tool, the single short sentence is arguably too terse to be considered fully appropriately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of annotations, 0% schema description coverage, and no output schema, the description should explain required fields and creation behavior. It only states the basic action and optional linkages, leaving important context missing for a six-parameter mutation tool.

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

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

Schema description coverage is 0%, so the description must compensate for six undocumented parameters. It only clarifies that user_story_id and sprint_id are optional link targets, leaving required parameters like project_id and subject, as well as assigned_to and description, without added meaning.

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

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

The description states a specific verb and resource: "Create a task." It also adds scope by noting optional linkage to a user story or sprint, which helps distinguish it from generic create tools. It does not explicitly name sibling alternatives, but the resource is clear.

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

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

The description gives no guidance on when to use this tool versus related tools such as taiga_create_user_story or taiga_create_issue. It only describes what can be linked, not when a task is the appropriate artifact or what prerequisites are required.

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

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

No annotations are supplied, so the description carries the full burden: it does not mention permissions, duplicate-subject behavior, side effects such as sprint assignment moving the story, or what the call returns. It does disclose one genuinely non-obvious behavioral constraint (epic_id is an internal numeric ID, not the UI ref #), which lifts it above a bare minimum.

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

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

Two sentences, zero filler, with the field list leading and the high-risk epic_id warning flagged with "IMPORTANT" so it is not skimmed past. Every clause carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema and no annotations, so the description should state what is returned (e.g., the created story with its ID) and note any auth or project-membership requirement; it does neither. Field coverage is good, but for a 7-parameter mutation tool with zero structured support, the return/behavior surface is left blank.

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

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

Schema description coverage is only 14%, but the description compensates well: it maps subject, description (clarified as acceptance criteria), tags, sprint, assignee, and optional epic, and explains the non-obvious epic_id format. The required project_id is never explained, and sprint_id vs. project_id semantics remain undocumented.

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

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

Opens with a specific verb+resource ("Create a user story") and enumerates the fields it accepts, so the agent immediately knows what this tool produces. It does not distinguish itself from the sibling taiga_bulk_create_stories, which is a plausible confusion point for an agent creating multiple items.

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

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

Gives a concrete prerequisite workflow for the tricky case — call taiga_list_epics or taiga_resolve_ref first to obtain the internal epic ID. It offers no exclusions or alternatives for related paths (bulk creation, or creating a task/issue instead), so it stops short of full 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.

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

There are no annotations, so the description carries the full behavioral burden for a mutation tool. It only mentions slug formatting and omits permissions, duplicate-slug behavior, side effects, error cases, and what is returned after creation.

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

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

Two short sentences, front-loaded with the action and followed by a useful slug constraint. The second sentence is partly redundant with the schema, but the description remains efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a create mutation with no annotations and no output schema, the description is too thin. It leaves the required project_id unexplained and provides no context about permissions, duplicate handling, or post-creation behavior.

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

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

Schema coverage is 67%: slug and content are documented in the schema, while project_id has no description anywhere. The description repeats the schema's slug guidance and adds an example, but does not compensate for the unexplained required project_id parameter.

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

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

The description states a specific verb and resource: 'Create a new wiki page.' It is clearly distinguishable from list/get/update/delete wiki siblings by the verb, though it does not explicitly compare itself to those alternatives.

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

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

It provides no guidance on when to use this tool versus taiga_update_wiki_page or other creation tools, and no prerequisites such as required project permissions or existing project context.

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

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

No annotations are provided, so the description carries the full burden, and it does disclose two critical traits: permanence/irreversibility and cascade behavior (contained stories persist, merely unlinked). It omits permission requirements and what happens to tasks/issues on those stories, keeping it short of a 5.

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

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

Two short sentences, zero waste, with the destructive semantics and side effect front-loaded before the irreversibility warning. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter destructive tool with no output schema and no annotations, the description covers what gets destroyed and what survives. Missing permission/confirmation context is a minor gap but not a blocking one.

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

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

Schema description coverage is 100% and the single epic_id parameter is documented in-schema as 'Internal epic ID (not ref #)'. The description adds nothing beyond that, so the baseline 3 applies.

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

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

Names a specific verb and resource ('delete an epic') and adds the key scope detail that stories are not deleted but unlinked. It does not explicitly name the sibling it differs from (e.g. taiga_unlink_story_from_epic or taiga_delete_user_story), so sibling differentiation is implicit rather than stated.

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

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

'Irreversible' implies caution and 'stories survive, unlinked' hints at why one might choose this over other removal paths, but there is no explicit when-to-use/when-not guidance or named alternative (e.g. unlink instead of delete). Usage is inferable, not instructed.

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

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

With no annotations, the description carries the full burden; it does disclose the critical trait — irreversibility — which is exactly the risk signal an agent needs for a destructive tool. However, it says nothing about required permissions, whether related comments/attachments are cascaded or orphaned, or failure behavior on a nonexistent ID.

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

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

Two sentences, zero filler, and the destructive nature is front-loaded. It is arguably terse to the point of omitting useful structure, but nothing written is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter destructive tool with no annotations and no output schema, the description covers the essential irreversibility but omits permissions, cascade effects, and confirmation expectations. Adequate, but a gap remains for an irreversible operation.

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

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

There is only one parameter and the schema fully documents it, including the important disambiguation that it is the internal ID rather than the ref number. The description adds nothing beyond that, which is acceptable given 100% schema coverage.

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

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

States a specific verb and resource ('Permanently delete an issue'), which is unambiguous against get/update/create issue siblings. It does not explicitly route to alternatives such as update_issue for non-destructive status changes, so it stops short of the top band.

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

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

The description gives no when-to-use guidance, no prerequisites, and no named alternative (e.g., closing or updating the issue instead). The only implicit signal is 'Permanently', leaving scope decisions to inference.

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

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

With no annotations, the description must carry the full behavioral load; it correctly discloses that the operation is permanent and irreversible, which is valuable. It stops short of stating whether child tasks/comments are also removed, what permission level is required, or what the response contains.

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

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

Two sentences, both front-loaded: the action first, the safety warning second. No filler whatsoever.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter destructive call with no output schema, the description covers the essential facts (what it deletes, that it's permanent). It could add cascade effects or required permissions, but the core is adequate.

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

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

Only one parameter exists and the schema documents it fully ('Internal story ID (not ref #)'), so the baseline is 4. The description adds no parameter detail beyond that, but none is needed.

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

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

States a specific verb ('Permanently delete') and resource ('a user story'), which cleanly separates it from taiga_update_user_story and from the similarly-named delete tools for epics, issues, and wiki pages. No ambiguity about what the tool does.

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

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

The line about confirming with the user before bulk deletions gives one concrete usage caution, but nothing frames when to choose deletion over an alternative (e.g., closing/archiving a story) or what prerequisites exist. Usage context is implied rather than spelled out.

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

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

With no annotations, the description carries the full burden; it does disclose the single most important trait, that deletion is irreversible and permanent. It says nothing about what is destroyed alongside the page (comments, attachments, children), whether confirmation or elevated permissions are required, or how a missing slug is handled.

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

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

Two short sentences, zero filler, and the destructive nature is front-loaded. It is arguably under-sized for a zero-annotation destructive tool, but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive operation with no annotations, no output schema, and two fully undocumented parameters, the description is too thin: it omits confirmation/permission expectations, cascade effects, and the meaning of project_id. An agent can call it, but risks calling it against the wrong page.

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

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

Schema description coverage is 0%, so the description must compensate. It only clarifies that the page is identified by slug and never mentions project_id, its role in scoping the lookup, expected slug format, or ID source.

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

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

States a specific verb and resource ('Permanently delete a wiki page') plus the identifying key ('by slug'), which cleanly separates it from taiga_update_wiki_page and taiga_create_wiki_page. It does not explicitly name a sibling or scope, but the action is unambiguous.

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

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

There is no guidance on when to use this versus updating or archiving a page, no prerequisites, and no warning about verifying the target before calling. The only implicit signal is the word 'Permanently', which the agent must interpret on its own.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the response includes 'description and linked user stories', which is valuable return-content context, but it does not mention read-only safety, permission requirements, not-found behavior, or error handling.

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

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

The definition is a single front-loaded sentence that immediately states the action and the key return content. There is no redundant or filler text.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter getter with no annotations and no output schema, the description gives a useful hint about returned details. However, it omits parameter semantics, error behavior, and authentication requirements, leaving meaningful gaps for an agent invoking the tool.

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

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

Schema description coverage is 0%, so the single parameter epic_id has no structured documentation. The description does not mention the parameter at all, leaving its meaning to be inferred solely from the name; it does not compensate for the coverage gap with format or example details.

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

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

The description uses a specific verb ('Get') and resource ('full epic details'), making it clear this retrieves a single epic rather than listing epics. It does not explicitly name sibling alternatives like taiga_list_epics, but the distinction is inferable from 'full epic details'.

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

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

Usage is implied by the verb 'Get' and the mention of 'full epic details', suggesting it is for retrieving one epic when you already know its ID. However, there is no explicit guidance about when to use this versus taiga_list_epics or how to obtain the epic_id.

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

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

No annotations exist, so the description carries the burden; it discloses the return content (description plus comments) and the ID semantics that govern correct invocation. It does not mention permissions, or how comments are ordered/truncated, which leaves a small gap for a read tool of this shape.

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

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

Three short sentences, front-loaded with the return contract, then the sibling contrast, then the ID caveat. No restatement of the name and no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description adequately explains what comes back, and the single-parameter surface is fully covered. Minor omission: nothing about ordering, size, or error behavior when the ID does not exist.

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

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

Schema coverage is 0% and the single parameter is bare ('issue_id': integer), so the description must compensate — and it does, specifying that the value is the internal id (not a # ref) and routing users to taiga_resolve_ref for conversion. That is precisely the semantic the schema lacks.

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

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

States a specific verb and resource ('Get full issue details') and, unusually, spells out the returned payload ('description AND comments'). It explicitly contrasts with the sibling taiga_list_issues, so the agent can differentiate without opening either schema.

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

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

Gives an explicit when-to-use rule versus taiga_list_issues ('returns only subject/status/assignee, so this is the only way to read what an issue actually says') and a prerequisite step ('use taiga_resolve_ref to convert a # ref first'). That covers both alternative selection and preconditions.

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

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

No annotations are present, so the description carries the burden. It usefully discloses the returned content (members, statuses, roles, priorities, issue types), which signals a read-only detail retrieval, but it says nothing about permissions, error behavior, or whether the nested data is paginated.

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

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

A single front-loaded sentence with zero filler. Every listed item adds useful scope information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter GET, the payload enumeration is helpful and there is no output schema to require return-value documentation. However, the missing parameter meaning and absence of any behavioral context leave meaningful gaps.

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

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

The single required parameter project_id has 0% schema description coverage, and the description does not explain where to obtain the ID or what format it expects. With low 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.

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

States a specific verb ('Get') and resource ('project details'), and enumerates the subresources returned (members, statuses, roles, priorities, issue types). It does not explicitly distinguish itself from taiga_list_projects, but the detail-oriented payload makes the purpose clear.

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

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

No guidance on when to use this versus taiga_list_projects or other siblings, and no prerequisites or exclusions are given. The word 'Get' implies retrieval by ID, but the description leaves routing entirely to inference.

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

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

With no annotations, the description carries the full disclosure burden. It does reveal that the response includes all stories, implying a potentially large payload, but says nothing about read-only semantics, error behavior for an unknown sprint_id, permission requirements, or whether pagination applies to the embedded stories.

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

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

A single front-loaded sentence with no filler; the most decision-relevant fact (that stories are included) is stated up front. It is arguably too terse for a 0%-coverage schema, but nothing in it is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter read tool with no output schema, the description covers the essential shape of the response (sprint details plus stories). It stops short of explaining the required identifier or failure modes, which leaves a meaningful gap given there are no annotations or schema descriptions to fall back on.

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

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

Schema description coverage is 0% for the single parameter, and the description adds nothing about sprint_id — no indication of where to obtain it (e.g., from taiga_list_sprints) or whether it is the numeric sprint ID versus a slug or ref. The description neither names nor explains the one input the agent must supply.

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

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

The description states a specific verb ('Get') and resource ('sprint details') and adds that the response embeds all stories in the sprint, which is genuinely useful scope information. It does not explicitly contrast itself with taiga_list_sprints or taiga_get_user_story, so an agent must infer the list-vs-single distinction from the name alone.

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

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

There is no guidance on when to use this tool rather than taiga_list_sprints (to enumerate sprints) or taiga_get_user_story (to fetch a story individually). No prerequisites, no mention of needing a valid sprint_id obtained elsewhere, and no exclusions.

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

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

With no annotations, the description carries the full load, and 'Get' plus the enumerated fields do establish a read-only retrieval returning description, tasks, and comments. It says nothing about behavior for a nonexistent or inaccessible story, nor about permissions or whether comments/tasks are truncated.

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

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

One short sentence with the resource and returned payload front-loaded; nothing is wasted. It is arguably too terse rather than padded, but nothing needs trimming.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with no output schema, the description gives a usable sense of the return payload (description, tasks, comments) but omits identifier semantics and failure behavior. It is adequate but leaves real gaps for an agent calling it cold.

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

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

Schema description coverage is 0%, so the description must compensate, but it never mentions story_id at all — not whether it is the numeric Taiga story ID, a ref, or a slug. The single parameter is left entirely to the schema's bare 'integer' type.

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

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

States a specific verb and resource ('Get full story details') and enumerates what comes back (description, tasks, comments), which distinguishes it from the list/form siblings. It does not explicitly name taiga_list_user_stories as the alternative, so it falls short of full sibling differentiation.

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

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

There is no guidance on when to use this versus taiga_list_user_stories or taiga_resolve_ref, and no prerequisite such as how to obtain a valid story_id. The agent must infer that this is the single-item fetch used after a listing call.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Get' hints at a read-only operation, but the description says nothing about return format (markdown vs HTML), error behavior for a nonexistent slug, or project scoping requirements.

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

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

A single, front-loaded sentence with no filler. It is efficient, though the brevity reflects under-specification rather than disciplined editing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read tool with no annotations and no output schema, the description should at least explain what 'full content' looks like and why project_id is required alongside a slug. Neither is covered, leaving the agent to guess at behavior and return shape.

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

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

Schema coverage is only 50%: 'slug' is documented in the schema and merely echoed in the description, while 'project_id' is undocumented in both places. The description adds no meaning beyond the schema and leaves the required project scoping unexplained.

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

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

States a specific verb ('Get') and resource ('wiki page') and adds scope ('full content'), which implicitly distinguishes it from taiga_list_wiki_pages (which returns page summaries). It does not name a sibling explicitly, so differentiation is inferred rather than stated.

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

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

There is no guidance on when to use this versus taiga_list_wiki_pages (to discover slugs) or taiga_search/taiga_resolve_ref. The description never says that a slug must first be obtained from the list tool, nor what to do when a slug is unknown.

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

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

No annotations are provided, so the description carries the burden. It meaningfully discloses the internal-ID requirement and the resolve_ref pathway, but it does not say whether linking replaces an existing epic association, whether the call is idempotent, what permissions are needed, or what is returned. Adequate but with real gaps for a mutation tool.

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

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

Three short sentences, front-loaded with the action, then the ID constraint, then the remediation step. Every sentence adds information; nothing is padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter mutation with no annotations and no output schema, the description covers input format and the ref-resolution workflow, which is the main failure mode. It omits behavior on re-link/conflict and any hint of the response, leaving an agent unable to predict the outcome of the call.

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

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

Schema description coverage is 100% and both properties already state 'Internal epic ID (not ref #)' and 'Internal story ID (not ref #)'. The description only restates that constraint, so the schema does the heavy lifting and the baseline of 3 applies.

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

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

The description opens with a specific verb and resource ('Link an existing user story to an epic'), which is unambiguous and immediately distinguishes it from taiga_unlink_story_from_epic and from the create/update story tools.

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

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

It gives concrete pre-call guidance: both IDs must be internal, and taiga_resolve_ref should be used to convert ref numbers first. That covers the main prerequisite. It does not say when not to use it (e.g., if the story is already linked, or vs. setting an epic field on create), 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.

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that returned epics include status, assignee, and story count, but it does not state whether the operation is read-only, whether pagination applies, how results are ordered, or what permissions are required.

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

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

The description is a single front-loaded sentence with no wasted words. It states the action, scope, and returned fields efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero schema descriptions, no annotations, and no output schema, the description is too sparse to be complete. It should clarify that status and assigned_to are optional filters and describe return behavior such as pagination or ordering.

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

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

Schema description coverage is 0%, so the description must compensate for three undocumented parameters. It mentions 'status' and 'assignee' only as returned fields, not as optional filters, and it does not explain project_id, assigned_to format, or whether status and assigned_to narrow the result set.

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

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

The description gives a clear verb and resource: 'List all epics in a project', and it identifies the fields returned (status, assignee, story count). It distinguishes itself from single-epic tools like taiga_get_epic by scope, but it does not explicitly name alternatives such as taiga_get_epic or taiga_list_user_stories.

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

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

Usage is implied by 'List all epics in a project', which suggests bulk enumeration rather than fetching a single epic. However, there is no explicit when-to-use guidance, no exclusions, and no mention of when to prefer taiga_get_epic or how to filter results.

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

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

With no annotations, the description carries the full burden; it usefully discloses that only summary fields are returned, which sets expectations about the payload. It says nothing about pagination, result size limits, ordering, or permissions, all of which matter for a list operation against a project.

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

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

Two compact sentences with zero filler; the primary purpose comes first and the sibling routing follows. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter read tool with no output schema, the definition covers what it returns and where to go for detail, which is enough to call it correctly. Pagination behavior is the one remaining gap.

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

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

Schema coverage is 0% and the single required project_id has no schema description, so the description must compensate. 'In a project' does imply that the parameter scopes the listing, but it adds no format or validity detail beyond the obvious.

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

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

States a specific verb and resource ('List all issues in a project') and immediately distinguishes the result from the sibling taiga_get_issue, which returns full detail. An agent can select it without opening the schema.

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

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

Explicitly routes the agent to taiga_get_issue when the description or comments are needed, which is the key alternative here. It offers no guidance on the other conditions that matter (pagination, result volume, filtering by status/assignee), so it is clear but not exhaustive.

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

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

No annotations are provided, so the description carries the disclosure burden; it indicates permission-scoped results via "accessible" and signals the return shape via "ID, name, slug." However, it omits pagination behavior, ordering, rate limits, and explicit read-only safety context.

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

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

The description is a single front-loaded sentence with no filler. It immediately states the operation, scope, and key returned fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter list tool with no output schema, the description supplies the essential return fields and access scope. It is nearly complete, though pagination or ordering details would make it fully self-contained.

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

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

The tool has zero parameters, so there are no parameter semantics to clarify; the description appropriately focuses on behavior and return fields. With no parameters and full schema coverage, this is the expected baseline.

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

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

The description states a specific verb, "List," and a specific resource, "Taiga projects," and identifies the returned fields "ID, name, slug." It does not explicitly name the sibling taiga_get_project, but the plural/all scope still makes the enumerating purpose clear.

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

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

The phrase "List all accessible" implies the tool is for enumerating projects available to the caller, but there is no explicit guidance on when to use it versus taiga_get_project or when not to use it. Usage 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.

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond the basic read operation. It says nothing about pagination, whether closed/completed sprints are returned, ordering, or what permissions are needed to list sprints in a project.

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

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

One short sentence with the action and scope front-loaded and no filler. Its brevity is appropriate, though the space saved is not reinvested in any needed detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a trivial one-parameter list tool with no output schema and no annotations, the description should still cover return shape, pagination, and what 'all' includes. None of that is present, leaving an agent to discover behavior by calling it.

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

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

Schema description coverage is 0%, so the description must compensate for the single undocumented parameter. Its phrase 'for a project' weakly implies project_id identifies a project, but it never specifies whether the integer is a numeric project ID, and no format or constraint is given.

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

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

States a specific verb (list) and resource (sprints/milestones) scoped to a project, which lets an agent separate it from taiga_get_sprint or taiga_create_sprint by verb alone. It does not explicitly name a sibling or state scope restrictions (open vs. closed sprints), so it stops short of a 5.

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

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

There is no when-to-use or when-not-to-use guidance, and no alternative is named (e.g., taiga_get_sprint for a single sprint, or filtering options). The only hint is 'for a project', which is inferable from the required parameter rather than stated as guidance.

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

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

With no annotations, the description carries the full burden. It implies a read operation only through the verb 'List' and says nothing about pagination, default ordering, result limits, or whether unfiltered calls return the entire backlog — meaningful gaps for a list endpoint on a large project.

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

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

Two short sentences, purpose front-loaded and filters second. Every clause earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter list tool with no annotations, no output schema, and zero schema description coverage, the description leaves too much unsaid: the required project_id scope, pagination behavior, and what a returned user story contains are all absent.

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

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

Schema description coverage is 0%, so the description must compensate; it does explain what four of the five parameters mean, including that assigned_to takes a username rather than a numeric ID. However, the required project_id is never mentioned and no parameter formats, defaults, or accepted status values (enum-free string) are given.

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

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

The description names a specific verb and resource ('List user stories') and enumerates the available filters, so its function is unambiguous. It does not, however, distinguish itself from siblings such as taiga_search or taiga_get_user_story, which an agent could plausibly confuse for retrieval.

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

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

Naming the four filters implies the situations the tool serves (filtering a project's backlog by state/sprint/epic/assignee), but there is no explicit when-to-use guidance, no mention of taiga_search as the alternative for free-text lookup, and no note that project_id is mandatory.

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

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

With no annotations at all, the description carries the full behavioral burden. It reveals the returned fields (slug, title), which is useful, but says nothing about pagination or result limits, ordering, whether archived pages are included, or the read-only nature of the call.

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

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

One short, front-loaded sentence with no wasted words. It is efficient, though its brevity contributes to the gaps elsewhere rather than being a virtue in itself.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter list tool with no output schema, the essentials are present: what is listed, the scope, and the returned fields. Missing pagination/completeness details and project_id provenance leave it only marginally adequate.

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

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

Schema description coverage is 0% for the single required integer project_id. The phrase 'in a project' implies the parameter identifies the project, but the description never states the ID format or that it comes from taiga_list_projects, so it only partially compensates.

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

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

States a specific verb and resource ('List all wiki pages') scoped to a project, and even names the returned fields (slug and title). It does not explicitly contrast with the sibling taiga_get_wiki_page for single-page retrieval, which keeps it from a 5.

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

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

There is only an implied usage: it lists pages, so use it when you need a listing. Nothing says when to prefer this over taiga_search or taiga_get_wiki_page, nor are any prerequisites for the project stated.

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

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

No annotations exist, so the description carries the full burden. It communicates the intended read-only mapping behavior and the required ordering, but says nothing about failure modes (ref not found, ref belonging to a different project) or whether the ref is validated against object_type.

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

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

Two sentences, front-loaded with what it does and followed by the mandatory usage rule; there is no filler or restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description does state the return value ('the internal ID'), and the pre-call ordering rule is clear. The only shortfall is the missing per-project scoping rationale for project_id, which matters for a 3-required-parameter tool.

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

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

ref and object_type are already described in the schema (the enum enumerates the four valid types). project_id is undocumented in both places, and the description misses the key semantic that # references are scoped per project, which is what makes project_id required rather than redundant.

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

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

States a specific verb and resource ('Convert a display reference number ... to the internal ID') and even grounds it with a concrete example ('#12 shown in the UI'). No sibling tool does reference-to-ID resolution, so it is unambiguous against the list/get/update family.

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

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

Gives an explicit precondition with 'ALWAYS use this before commenting on or updating a story/task/issue by its # number', naming the downstream tools (taiga_add_comment, taiga_update_*) and the condition that selects them. The agent knows both when to call it and what it unlocks.

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

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

No annotations are provided, so the description carries the full burden and does not meet it. It says nothing about matching semantics (title vs body, substring vs full-text, case sensitivity), result limits, pagination, or ordering — all of which materially affect whether an agent can use the results.

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

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

A single front-loaded sentence with no filler. It is efficient, though the brevity comes at the cost of the behavioral detail an agent needs, which is penalized in other dimensions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an unannotated, two-parameter search with no output schema, the description omits what the results look like (grouped by type? mixed? fields per hit?), how matches are determined, and any result caps. An agent cannot predict the response shape or matching behavior from this definition.

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

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

Schema description coverage is 0% for both parameters. 'In a project' weakly implies project_id scope and 'search' implies the query, but neither the query syntax nor whether project_id constrains results to a single project is stated, so the description adds almost nothing beyond the parameter names.

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

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

States a specific verb (search) and enumerates the resource types searched (stories, tasks, issues, wiki), scoped to a project. That distinguishes it from the type-specific siblings like taiga_list_user_stories or taiga_list_wiki_pages, though it never explicitly names the contrast.

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

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

Usage is only implied: the enumeration of multiple content types suggests this is the cross-cutting search to use when the entity type is unknown. There is no explicit statement of when to prefer it over taiga_list_* or taiga_resolve_ref, and no prerequisites or exclusion conditions.

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

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

No annotations are provided, so the description carries the full disclosure burden. It implies unlinking rather than deleting the story, which is useful, but says nothing about permissions, reversibility, whether the epic is required to already contain the story, or what the response looks like.

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

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

A single front-loaded sentence with no waste, but its brevity comes from under-specification rather than efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations, no output schema, and fully undocumented parameters, the description does too little. It should at minimum clarify that the story itself survives and describe the required identifiers.

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

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

Schema description coverage is 0%, and the description mentions neither epic_id nor story_id. The parameter names are largely self-explanatory, but the description adds no semantics such as whether ids are the numeric Taiga ids or refs.

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

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

States a specific verb and resource (remove a user story from an epic) and is clearly distinguishable from taiga_link_story_to_epic. It does not explicitly name the sibling, but the operation is unambiguous.

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

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

No guidance on when to use this versus alternatives such as delete_user_story or link_story_to_epic, and no prerequisites or preconditions are stated. The agent must infer usage entirely from the name.

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

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

With no annotations, the description carries the full burden. It does disclose two non-obvious behaviors: status is given by name rather than ID, and 'comment' is posted atomically in the same call. It stays silent on partial-update semantics (whether omitted fields are preserved), permissions, and failure behavior, which matter for an 8-parameter mutation.

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

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

Two short sentences with zero filler, field list front-loaded and the atomic-comment caveat placed last where it is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No annotations and no output schema, and the description does not say what the call returns (updated epic? partial?) or how errors are surfaced. Adequate to make the call, but thin for a mutation with 8 parameters and no structured safety metadata.

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

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

Schema description coverage is only 25% (only assigned_to and comment are documented), so the description has to compensate. It meaningfully adds that status is passed by name, but leaves epic_id, tags, color, subject, and description formats unexplained beyond their types.

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

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

States a specific verb and resource ("Update epic fields") and enumerates which fields, so it is distinguishable from taiga_update_user_story and taiga_update_issue by resource alone. It does not explicitly name siblings, but the resource noun does the differentiation.

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

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

No guidance on when to use this versus taiga_create_epic, taiga_delete_epic, or taiga_add_comment for pure commenting. No prerequisites such as project membership or permissions are mentioned.

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

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

No annotations exist, so the description carries the full burden. It does add real behavioral value: 'comment' is posted atomically with the update, and status 'Closed' resolves the issue. But it never explains whether omitted fields are preserved or cleared (critical for a partial-update tool), what permissions are needed, or what the call returns.

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

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

Two sentences, both front-loaded with the actionable content: fields first, the atomic-comment trick second. Zero filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter mutation tool with no annotations and no output schema, the description covers which fields can change and one side effect, but leaves the partial-update contract, required permissions, and return value entirely unaddressed.

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

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

Schema coverage is only 33%, and the description mostly just re-lists parameter names (priority, severity, tags) whose schemas have no descriptions or enums, so the agent gets no valid value guidance for them. It adds meaning for 'status' ('Closed' resolves) but also says 'assignee' while the actual parameter is 'assigned_to', a naming mismatch that could cause a wrong key.

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

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

States a specific verb+resource ('Update an issue') and enumerates the mutable fields, which cleanly separates it from siblings like taiga_update_user_story and taiga_update_epic. It stops short of describing scope or prerequisites, but 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.

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

Usage is only implied ('Update an issue'). The comment sentence hints at an alternative to taiga_add_comment, but it never explicitly says when to use this tool versus posting a standalone comment, nor does it mention that the issue must already exist or how to resolve the ID (taiga_resolve_ref).

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

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

No annotations, so the description carries the full behavioral burden and largely does not: it never says if this is a partial update (omitted fields untouched), what errors occur on unknown status names, or whether the comment fails the whole update. It does add one useful trait — that 'comment' is posted in the same call — but that is already in the schema.

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

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

Two compact sentences with the mutable-field list front-loaded and the comment side-effect second. Slightly list-heavy but no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A mutation tool with no annotations, no output schema, 8 parameters, and 25% schema coverage needs far more: partial-update semantics, status-name failure behavior, atomicity on failure, and unassign/empty-string conventions for the remaining fields are all absent.

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

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

Schema coverage is only 25%, so the description must compensate, yet it only adds the meaningful note that status is passed by name rather than ID. sprint_id, tags, subject, and description get no semantics in either place, leaving half the parameters effectively undocumented.

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

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

States a specific verb and resource ("Update story fields") and enumerates the mutable fields, so an agent knows exactly what the call does. The resource name alone distinguishes it from siblings like taiga_update_issue and taiga_update_epic, but no explicit sibling differentiation is offered.

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

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

There is no statement of when to use this tool versus taiga_create_user_story, taiga_add_comment, or taiga_get_user_story first to check state. Usage is only implied by the name. No prerequisites (permissions, existing story_id) are mentioned.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds one important trait—it creates the page if it does not exist—but omits permission requirements, whether existing content is fully overwritten, what happens to other page metadata, and what the response looks like.

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

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

The definition is two short sentences with no wasted text. The core action is front-loaded, and the creation fallback follows immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a mutation tool with no annotations, no output schema, three required parameters, and incomplete schema coverage. The description discloses the upsert behavior but leaves out consequential details such as permission needs, overwrite behavior, and the undocumented project_id parameter.

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

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

Schema description coverage is only 33%, with only the content parameter documented in the schema. The description mentions updating content by slug, but it does not explain project_id at all and adds little parameter meaning beyond the schema. With low coverage, the description should compensate more than it does.

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

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

The description states a specific verb and resource: update the content of an existing wiki page by slug. It also discloses the upsert behavior, which distinguishes it somewhat from a pure update. It does not explicitly contrast with taiga_create_wiki_page, so it is clear but not fully differentiated from its closest sibling.

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

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

Usage is implied by 'update the content of an existing wiki page by slug,' and the fallback creation behavior gives some context. However, it does not say when to use this tool versus taiga_create_wiki_page or when an explicit create is preferred. No prerequisites or exclusions are provided.

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