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

With no annotations, the description must carry the full burden of disclosing effects, reversibility, permissions, or side effects. It only states the action "Archive a card" and adds no behavioral details beyond the verb itself.

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

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

The description is extremely concise and front-loaded with the verb, using a single efficient sentence. However, it borders on under-specification, which slightly reduces the score despite its brevity.

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

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

The description is minimal and lacks any context about archiving behavior, such as whether it is reversible, how it affects card visibility, or when it should be used. Even though an output schema exists, the description is insufficient for an agent to understand the tool's purpose and effect.

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

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

The schema has one required parameter, card_id, but the description provides no additional meaning. With schema description coverage at 0%, the description fails to compensate, leaving the parameter's purpose and constraints entirely 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 clearly states the action (archive) and the resource (card), which is specific and unambiguous. However, it does not explicitly distinguish from related operations like move_card or update_card, so it lacks sibling differentiation.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention any use cases, prerequisites, or exclusion criteria, leaving the agent without context for selection.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It only clarifies two parameter semantics (priority, category_name) and does not mention required permissions, side effects of creation, or response behavior. This is insufficient for a mutation tool.

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

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

The description is two sentences with zero unnecessary words. It front-loads the primary purpose and then adds two key parameter clarifications, making it efficient and 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?

Despite having an output schema, the description lacks essential context for a tool with 11 parameters. It does not state that project_id is required or how to obtain valid IDs, nor does it relate to sibling tools like list_projects. The parameter coverage is minimal, making the tool difficult to use correctly without additional information.

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 explains priority (1-5 scale) and category_name (column name), but 9 of 11 parameters (body, points, epic_id, label_ids, sprint_id, assignee_ids, workspace_id) receive no elaboration, leaving the agent to infer meaning from type alone.

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 explicitly states the tool creates a new card (issue) in a project, using a specific verb and resource. This distinguishes it from siblings like update_card, move_card, and archive_card, and clarifies the domain terminology.

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 'create' but there is no explicit guidance on when to use this tool versus alternatives like create_ticket, or any prerequisites such as needing a project_id. No exclusions or conditions 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?

With no annotations, the description carries the full burden of behavioral disclosure, but it merely restates the tool's name without adding context. It does not mention permissions, failure conditions, that the comment will be appended, or any side effects, leaving the agent with only the basic verb 'add'.

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, compact sentence that immediately states the action. Every word contributes to clarity, and there is no redundancy or unnecessary 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 simple create operation with only two required parameters and an output schema, the description is minimally adequate. However, it lacks usage guidance, behavioral caveats, and parameter elaboration, making it only partially complete for an agent attempting to decide when and how to invoke 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%, and the description provides no parameter information whatsoever. While the parameter names (card_id, body) are self-explanatory, the description fails to compensate for the lack of schema descriptions, offering no added meaning beyond the raw schema.

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

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

The description uses the specific verb 'Add' and the resource 'comment to a card', making the action unambiguous. It clearly distinguishes from sibling comment tools (list, update, delete) by conveying that this is the creation operation.

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 is given on when to use this tool versus alternatives such as list_card_comments, update_card_comment, or delete_card_comment. The description does not state that this is for creating new comments only, nor does it mention any prerequisites or contextual scenarios.

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 clarifies the direction of the link (card_id shows the link, linked_card_id is linked to) but does not state any side effects, permissions, idempotency, or constraints (e.g., self-linking, duplicates). 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?

The description is two concise sentences: the first states the purpose, the second explains the parameters. It is front-loaded and contains 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?

Given the tool's simplicity (two parameters, no nested objects) and the presence of an output schema, the description adequately covers the essential aspects: what it does and what each parameter means. However, the lack of behavioral disclosure (side effects, prerequisites) slightly reduces completeness.

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 fully explains both parameters: card_id is the card that shows the link, and linked_card_id is the card it links to. This provides clear meaning beyond the raw field names and integer 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?

The description clearly states a specific action ('Create a Related Card link') and a specific resource ('between two cards'). It explicitly names the Zube 'Related cards' feature, distinguishing it from other card-related tools like create_card or update_card.

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

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

The description provides clear context: this tool is for creating a related card link between two cards. While it doesn't explicitly mention when not to use it or list alternatives, the purpose is unambiguous given the sibling tools, making the appropriate usage obvious.

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

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

No annotations are provided, so the description must disclose behavior. It only adds format constraints for color and due_on, but does not mention required permissions, failure modes, side effects, or whether the epic appears immediately. For a mutation tool, this is inadequate.

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

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

Two sentences with no filler; the format hints are directly useful. Well front-loaded with the action.

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?

Despite having an output schema, the tool has 8 parameters and zero annotations. The description does not explain the relationship between fields, how to obtain project_id, or the purpose of label_ids/track_cards. This is insufficient for reliable invocation.

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

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

The description covers only color and due_on formats for 2 of 8 parameters, leaving title, project_id, description, label_ids, assignee_id, and track_cards with only schema types and no semantic guidance. This does not compensate for the 0% schema description coverage.

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

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

The description uses a specific verb 'create' and resource 'epic' in a project, clearly indicating the tool's function. It distinguishes from sibling update_epic by implying creation vs modification, though it doesn't elaborate on epic-specific context.

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 is given on when to use this tool vs create_ticket or other creation tools, nor any prerequisites or alternatives. The description only states the action without contextual direction.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only adds the color format requirement ('hex code without #') but does not disclose side effects, whether labels can be duplicated, permission requirements, or what happens on failure. This is a significant gap for a create operation.

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

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

The description is extremely concise, comprising two short sentences. The first sentence states the purpose, and the second provides the key parameter detail. Every word earns its place, with no redundancy or fluff.

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

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

For a simple three-parameter create tool, the description covers the core action and the most non-obvious parameter format. The output schema exists, so return values need not be explained. However, it omits any context about project_id shape or preconditions (e.g., project must exist), making it minimally adequate but not thorough.

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 description adds meaningful detail for the 'color' parameter, explicitly specifying the accepted format. However, 'name' and 'project_id' are not described beyond their schema types and names. Since schema description coverage is 0%, the description should compensate more fully, but the provided color detail is valuable and the other parameters are fairly self-explanatory.

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

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

The description clearly states the tool's action ('Create a label') and scope ('in a project'), using a specific verb and resource. It distinguishes from sibling creation tools like create_card or create_epic by explicitly naming 'label' as the object.

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 is provided about when to use this tool versus alternatives, such as list_labels or similar creation tools. There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent to infer usage solely from the name.

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

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

With no annotations provided, the description must carry the burden of behavioral disclosure, but it only restates the core 'create' action without adding context like permissions, side effects, return format, or irreversibility. This is minimal and matches the level of the update_drive example.

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, direct sentence with no redundant wording, making it efficient and front-loaded. However, it may be under-specified for the task, but conciseness itself is strong.

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?

Despite the tool's low complexity (3 simple params) and presence of an output schema, the description is too minimal to be complete. It lacks critical context like what the response contains, behavioral nuances, or usage conditions, leaving significant gaps for the agent.

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

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

Schema description coverage is 0%, so the description needed to compensate, but it only implies that account_id is the parent scope. It fails to explain the meaning of 'name' or 'description' parameters, their constraints, or how they affect the created project.

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

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

The description clearly states the action ('Create'), the resource ('a new project'), and the scope ('within an account'), effectively distinguishing it from sibling tools like create_workspace and create_card. The verb+resource combination is specific and unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives such as update_project or create_workspace. It does not mention prerequisites, context, or exclusions, leaving the agent with only the action itself.

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

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

With no annotations, the description carries full responsibility for disclosing behavior, but it only states 'Create a sprint' and date format. It does not mention side effects, required permissions, whether a workspace must exist, validation logic, or what happens on failure. The description adds no behavioral transparency beyond the literal action.

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 sentence followed by a concise example. It is front-loaded with the core purpose ('Create a sprint') and contains no filler. Every word earns its place, making it highly 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?

The tool has 5 parameters, no annotations, and the description is very sparse. Even though an output schema exists, the description does not provide essential context such as the relationship between workspace_id and the sprint, required access levels, or how the start/end dates are validated. It is inadequate for a create operation with this complexity.

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

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

The description adds value by specifying that dates are ISO timestamps with an example, which goes beyond the schema's plain string type. However, schema description coverage is 0%, and the description does not explain workspace_id, title, or description meaningfully. The date format hint is useful but partial compensation for the lack of schema descriptions.

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 'Create a sprint' uses a specific verb and resource, clearly distinguishing it from sibling tools like 'update_sprint', 'get_sprint', and 'list_sprints'. The purpose is unambiguous, even though no additional context is provided.

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 is given about when to use this tool versus alternatives. It does not mention that 'create' is for new sprints while 'update_sprint' is for modifications, nor does it specify any prerequisites or exclusions. The only extra information is about date formatting, which is not usage-related.

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?

Annotations are absent, so the description must disclose behavioral traits. It only states that it creates a ticket and lists some field values. It does not mention permissions, idempotency, potential side effects, or post-creation behavior. The description does not contradict annotations (none), but it lacks substantive behavioral disclosure.

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

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

The description is two short sentences, so it is efficient. However, it is under-specified for a 10-parameter tool with no annotations. It does not earn its place fully; it leaves major gaps.

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

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

The tool is moderately complex (10 params, 2 required, no annotations, and an output schema exists but is not described). The description covers only ticket creation and two field hints, lacking context on required fields, defaults, or when to use. The output schema's existence reduces the need to explain return values, but the description still fails to provide enough context for correct selection and invocation.

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

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

The schema has 0% coverage, so the description must explain parameters. It adds value for priority (1-4, 1=highest) and implies a type enum, but it misnames the schema property 'ticket_type' as 'type', which could cause incorrect invocation. It also ignores the other eight parameters including required project_id and title. This is insufficient compensation for the schema's lack of descriptions.

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

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

The description clearly states the tool's function: 'Create a ticket.' This is a specific verb+resource pair that distinguishes it from sibling tools like update_ticket and list_tickets. The resource 'ticket' is distinct within the context of the other 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?

No guidance is provided on when to use create_ticket versus alternatives such as create_card or update_ticket. The mention of type and priority values is parameter-level advice, not usage context. There are no exclusions or prerequisites.

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 disclose behavioral traits, but it only states the action and scoping. It does not mention required permissions, potential side effects, or return behavior. The clarification that a workspace is a Kanban board adds some context but not enough behavioral transparency.

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

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

The description is a single, concise sentence that immediately states the core purpose. It is front-loaded and contains no superfluous 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?

Given the tool's low complexity (simple create operation with three parameters) and the presence of an output schema, the description provides sufficient context: it names the resource, its type (Kanban board), and the parent context (project). It lacks usage exclusions and parameter details, but these are not critical for a basic create 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. It only hints that projects are involved ('within a project') and does not explain the meaning or constraints of name, project_id, or description. The parameters are only formally defined in the schema without enrichment.

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

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

The description uses the specific verb 'Create' with the resource 'workspace (Kanban board)' and scopes it 'within a project.' This clearly distinguishes it from sibling tools like get_workspace, list_workspaces, and create_project.

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 creating workspaces in a project context, which gives clear context for when to use it. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a full 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without mentioning potential side effects, irreversibility, authorization needs, or error conditions. This is a minimal statement that adds no behavioral insight beyond the obvious 'delete' implication.

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, clear sentence with no redundant information. It is well-structured and easy to parse, earning full marks for conciseness.

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

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

For a simple delete operation with two parameters, the description is adequate but minimal. It provides no context about safety, permissions, or side effects, which would be expected given no annotations. The presence of an output schema is not enough to compensate for the lack of behavioral context, but the simplicity of the operation prevents a lower score.

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 adds little meaning beyond the parameter names. 'Delete a comment from a card' only implies that card_id identifies a card and comment_id a comment, but does not explain the relationship or any constraints. The description fails to compensate for the lack of schema descriptions.

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

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

The description 'Delete a comment from a card' uses a specific verb ('delete') and identifies the resource ('comment from a card'), clearly distinguishing it from sibling tools that create, update, or list comments. It is concise and unambiguous.

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

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

No usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor any prerequisites (e.g., comment must exist, permissions required). The value is essentially the same as the tool name, offering no additional context for selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read operation ('Get details') but does not explicitly state that it is non-mutating, mention authentication requirements, error behavior (e.g., 404 if not found), or describe what details are returned. It provides basic transparency but not comprehensive 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 or redundancy. It states the action and resource directly, earning its place entirely.

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

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

The tool is simple: one parameter, an output schema, and no nested objects. The description sufficiently conveys what the tool does and identifies the target resource. It could add usage context or mention the output schema explicitly, but given the low complexity, the description is essentially complete for a basic retrieve-by-ID 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?

The schema has 0% coverage from the description, and the sole parameter account_id is just an integer with no schema description. The description adds the context that the account is a Zube 'account (organization)', which clarifies what the ID represents, but it does not explain where to find this ID, its format, or any scoping nuances. This is partially compensating but not fully.

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 details') and clearly identifies the resource ('specific Zube account (organization)'). This distinguishes it from siblings like list_accounts and get_workspace, as it targets a single account rather than listing all or fetching a different entity.

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

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

The phrase 'specific' implies this is for looking up one account by ID, contrasting with list_accounts for enumerating all. However, there is no explicit guidance on when to use this tool versus alternatives, nor any stated exclusions or prerequisites. Usage is only implied, 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 must carry the burden. It discloses a read-only 'Get' operation and says it returns 'full details', but adds no specifics about error behavior, permissions, or side effects. This is adequate for a simple read tool but not rich.

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

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

Single sentence, front-loaded with the action, and zero filler. Every word earns its place.

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

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

For a one-parameter get-by-ID tool with an output schema, this description covers the purpose, parameter identity, and result scope. No additional context is necessary given the low complexity.

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

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

Schema has a single integer card_id with no description (0% coverage). The description fully compensates by clarifying that card_id is the 'internal ID', distinguishing it from card number lookups and giving meaning beyond the raw 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?

Description clearly states 'Get full details for a specific card by its internal ID' – a specific verb (Get), object (card), and disambiguates from sibling get_card_by_number by specifying 'internal ID'.

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?

Provides implicit context that this tool is for internal ID lookup, and the sibling list reveals get_card_by_number as alternative, but the description does not explicitly state when to choose one over the other or include any when-not-to-use guidance.

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

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

With no annotations, the description carries the full transparency burden. It states return behavior ('full card details including assignees and labels') and error handling ('Returns an error dict if no card is found'), which goes beyond the schema and provides useful behavioral context. It doesn't mention permissions or rate limits, but for a plain lookup this is reasonably transparent.

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, front-loaded sentences. The first sentence immediately states the action and resource; the second adds optional scoping and return/error behavior. Every word earns its place with no redundancy.

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

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

Given the low complexity (2 params, no enums, existing output schema), the description adequately covers purpose, parameter semantics, and error behavior. The optional project scoping is also covered. It is complete for an agent to select and invoke the tool correctly without additional context.

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

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

Schema coverage is 0% and the description fully compensates by explaining 'number' as a visible card number (e.g., #15293) and clarifying that project_id is optional scoping. This adds meaning beyond the bare integer/null schema types, making parameter purpose clear.

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 ('Look up') + resource ('a card') + scope ('by its visible card number'), clearly distinguishing it from sibling tools like get_card which likely queries by internal ID. The example (#15293) further clarifies the lookup mechanism.

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

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

The description clearly identifies the retrieval context (by visible card number, optionally scoped to a project) without explicitly naming alternative tools. It implies usage for when the visible number is known and provides optional scoping, which is actionable but lacks explicit when-not/exclusion 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 provided, the description carries the full burden. It only states the basic action and does not disclose any behavioral traits such as authentication requirements, potential errors, or what happens when no user is authenticated. The word 'authenticated' implies a requirement but does not elaborate.

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 unnecessary words. It is highly concise and structured effectively.

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

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

Given the tool's simplicity (0 parameters, output schema present), the description is largely sufficient. It clearly states what the tool does, though it does not mention error behavior or authentication prerequisites beyond the word 'authenticated.' This is a minor gap for such a simple getter.

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

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

The tool has zero parameters, and the input schema is empty, so the description does not need to explain parameters. Per the baseline for 0-param tools, a score of 4 is appropriate.

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

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

The description uses a specific verb ('Get') and identifies the exact resource ('currently authenticated Zube user's profile information'). It clearly distinguishes from sibling tools like get_account or get_workspace by specifying the current user.

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

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

The description clearly states the context: it returns the current authenticated user's profile, which implies when to use it. However, it does not explicitly mention alternatives or when not to use it, so it lacks exclusionary 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 of behavioral disclosure. 'Get details' implies a read-only operation, but there is no statement about error handling (e.g., 404 if not found), permissions, or side effects. The output schema captures return structure, but behavioral traits remain unaddressed.

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, complete sentence that states the core purpose without any filler or repetition. It is appropriately sized for a simple get operation, and every word earns its place.

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

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

The tool is simple, has two self-explanatory parameters, and an output schema exists so return values are not required in the description. However, the description lacks any usage context or behavioral notes, making it minimally viable but with clear gaps in guidance for an agent that must choose among many sibling tools.

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

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

Schema description coverage is 0% and the description does not compensate. The description never mentions project_id or epic_id, leaving the meaning of these parameters entirely to their names and types. No added value beyond the input schema, which already lists them as integers.

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 'Get details for a specific epic' clearly identifies the action (get) and resource (epic), with 'specific' implying a single item as opposed to listing. It distinguishes from sibling list_epics, though not explicitly naming it. It lacks the word 'by ID' but the schema supplies that.

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 is provided on when to use this tool versus alternatives like list_epics or get_card. No mention of prerequisites, such as needing a pre-existing epic_id, or that list_epics should be used to search for an epic first.

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 transparency burden. It discloses the notable behavior that the result includes both workspaces and sources, which is useful context beyond a plain 'get project.' It does not mention permissions, errors, or side effects, but the verb 'get' clearly implies a read-only operation, and an output schema exists to cover return structure.

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

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

The description is one short, front-loaded sentence that immediately states the action and object. The added detail 'including its workspaces and sources' is informative and compact, with 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 simple read operation with one required integer parameter and an output schema present, the description covers the core purpose and notes the inclusion of related resources. It does not discuss limitations or alternatives, but the low complexity and presence of an output schema make this a minor omission rather than a critical gap.

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

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

Schema description coverage is 0%, so the description needed to compensate for the lack of parameter details. However, it only says 'specific project,' which implicitly points to the project_id parameter but adds no meaning about the ID's type, format, or how to obtain it. The single parameter is self-explanatory from its name, but the description does not add significant value beyond the schema.

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

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

The description clearly states 'Get details for a specific project' with the specific verb 'get' and the resource 'specific project,' then adds 'including its workspaces and sources' to clarify scope. This distinguishes it from sibling tools like list_projects (which lists all projects) and get_workspace (which retrieves a single workspace).

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 'a specific project' implies that the tool should be used when you already have a project ID and need details for one project, as opposed to list_projects for all projects. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named.

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

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

No annotations are present, so the description carries the full behavioral disclosure burden. 'Get' implies a read-only operation, but the description does not mention error behavior, permissions, or what happens if the sprint is not found. This is minimal for a tool with no annotations.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the action and target.

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 getter with two required parameters and an output schema, the description is mostly sufficient. The output schema covers return details, and the operation is clear. It lacks behavioral/usage nuance, but that is accounted for in other dimensions.

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 adds no meaning to the sprint_id and workspace_id parameters. The agent must rely solely on the parameter names, which is insufficient given the complete lack of schema descriptions.

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

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

The description clearly identifies the verb ('Get') and resource ('specific sprint'), which distinguishes it from list_sprints. However, it does not explicitly name alternatives or specify which sprint details are returned, 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 guidance on when to use this tool versus alternatives like list_sprints or other get_* tools. The phrase 'specific sprint' implies retrieval by ID, but no explicit context 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.

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it gets details, but does not disclose the response structure, error behavior, required permissions, or that it is a read-only operation. The presence of an output schema is not referenced, leaving the agent without insight into what 'details' entails beyond 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?

The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple getter tool, achieving maximum conciseness.

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?

Despite having an output schema (which covers return values), the description lacks essential context. It does not indicate that both project_id and ticket_id are required, nor does it provide any usage scenario or integration with sibling tools. For a tool with zero annotations and zero schema coverage, the description is too minimal to be contextually 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 0%, so the description must compensate for the lack of parameter documentation. It does not mention project_id or ticket_id, nor explain their roles or constraints. The parameter names are self-explanatory, but the description adds no value beyond the schema, failing to meet the compensatory requirement for low coverage.

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

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

The description 'Get details for a specific ticket' uses a specific verb (get) and resource (ticket), clearly distinguishing it from sibling tools like list_tickets (which lists tickets) and create/update_ticket. It explicitly indicates it retrieves a single ticket, making its purpose unambiguous.

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

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

The description gives no guidance on when to use this tool versus alternatives such as list_tickets or get_card. It does not mention any exclusions, prerequisites, or contextual cues, leaving usage entirely implied by 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 provided, the description carries the full burden of behavioral disclosure. It indicates a read-only operation through 'Get' but does not mention return format, error behavior, or required permissions. For a simple get-by-ID tool, this is minimally acceptable but lacks additional 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 concise sentence that directly states the tool's purpose without any filler or redundant 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 tool with an output schema, the description is adequate. It clearly identifies the resource and operation, while the schema and output schema cover the technical details. The existence of sibling tools like list_workspaces provides surrounding context for how this tool fits into the broader API.

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

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

The schema defines one required integer parameter, workspace_id, and the description has 0% explicit coverage of it. However, the phrase 'specific workspace' implicitly references the ID, and the schema field name is self-explanatory. The description adds marginal meaning but does not fully compensate for the lack of parameter detail.

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

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

The description uses the verb 'Get' with a specific resource ('workspace'), clearly indicating a read operation for a single workspace. It distinguishes itself from sibling tools like list_workspaces and create_workspace by focusing on a specific identified workspace.

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

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

The description implies usage when a specific workspace ID is known, but provides no explicit guidance on when to use it versus list_workspaces or other workspace-related tools. It does not state any exclusions or alternatives, leaving the usage context implicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'List all members' which implies a read operation, but it does not disclose pagination behavior, potential rate limits, or any other traits beyond the obvious. The description adds no significant behavioral context beyond what the name already suggests.

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

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

The description is a single, front-loaded sentence that communicates the core purpose without any waste. It is appropriately sized for a simple list operation.

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

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

The description plus the input schema and output schema provide enough to invoke the tool correctly: the required account_id is clear, pagination parameters are self-explanatory from the schema, and an output schema exists. However, the description lacks guidance on usage boundaries or any additional behavioral context, making it minimally viable but not thorough.

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

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

The schema has 0% description coverage for its three parameters. The description clarifies that 'account' refers to an 'organization', adding slight meaning to account_id, but it completely ignores the pagination parameters (page and per_page). It fails to compensate for the schema's lack of descriptions, especially for pagination semantics.

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

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

The description clearly states the action ('List') and the resource ('all members of an account'), and it distinguishes itself from sibling tools like list_accounts (which lists accounts) and list_project_members (which lists project members) by specifying 'account (organization)'.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that it is the appropriate tool for listing account-level members or that list_project_members should be used for project members, leaving usage context implied at best.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and scope, while omitting pagination behavior, read-only nature, or any other operational traits.

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, focused sentence that is front-loaded and contains no unnecessary words.

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

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

The description conveys the core operation but omits parameter semantics and usage context. With an output schema present, return values need not be explained, yet pagination behavior remains undocumented.

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

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

The input schema has 0% description coverage and the description does not mention page or per_page. Although the parameter names imply pagination, the description adds no meaning beyond the schema.

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

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

The description clearly states 'List all Zube organizations (accounts) the current user belongs to,' using a specific verb and resource with a defined scope. This distinguishes it from get_account (single account) and list_account_members (members of an account).

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

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

The description implies usage for enumerating the current user's accounts but does not explicitly reference alternatives or exclusions. It lacks guidance on when to use this over related account-focused tools.

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

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

There are no annotations, and the description is essentially a restatement of the tool name. It does not disclose pagination behavior, ordering, return format, or any side effects, even though the schema indicates page and per_page parameters. Thus, the description adds no behavioral insight beyond what the operation name already implies.

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

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

The description is one short sentence, which is efficient, but it omits essential information about parameters and behavior. This is under-specification rather than appropriate conciseness, as evidenced by the need for additional context to correctly use the tool.

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?

Despite having an output schema, the description provides no contextual details about pagination, the structure of comments, or how this tool fits with sibling comment-related tools. It is minimally adequate for a basic understanding but insufficient for reliable tool selection and invocation in varied scenarios.

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 description does not mention any of the three parameters (card_id, page, per_page). With 0% schema description coverage, there is no compensation in the description, so the agent must rely entirely on the raw schema to understand parameter meanings and defaults.

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

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

The description uses the specific verb 'List' with the resource 'comments on a card', clearly identifying the operation. It implicitly distinguishes from sibling tools like create_card_comment and delete_card_comment by focusing on retrieval. The resource and scope are precise, making the purpose unambiguous.

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

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

The description provides no guidance on when to use this tool versus alternatives such as get_card or list_cards. It neither mentions contexts where it is appropriate nor explicitly excludes alternatives, leaving the agent to infer usage solely from the tool name.

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

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

With no annotations, the description carries the transparency burden. It discloses the list behavior and some parameter semantics (state open/closed, category_name as column name), but omits behavioral traits such as pagination behavior, default sort order, or that this is a read-only operation with no 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?

The description is concise and well-structured: a leading one-sentence summary followed by a compact list of filters and ordering instructions. Every sentence adds value, with no filler or redundant content.

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

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

Given the tool's complexity (12 parameters, many filters), the description is partially complete: it covers most filters and ordering, but misses pagination parameters and does not explain whether filters are combined with AND/OR logic. The presence of an output schema mitigates the need to describe return values, but usage guidance for this broad tool is still lacking.

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?

Despite the schema having 0% description coverage, the description compensates by listing most parameters and adding meaning beyond the schema, such as 'number' being a visible card number, 'category_name' being a column name, and 'state' being open/closed. However, it omits page and per_page pagination parameters, so it is not fully comprehensive.

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

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

The description clearly states the tool lists cards (issues/PRs) with optional filters, providing a specific verb and resource. However, it does not explicitly distinguish this from sibling listing tools like list_project_cards, list_triage_cards, or list_epic_cards, so it falls short of full 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?

The description gives clear context by enumerating available filters and order options, implying this is a general-purpose listing tool. However, it does not explicitly state when to use this tool versus alternatives, nor provide exclusions like 'use list_project_cards for project-scoped lists.'

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

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

With no annotations, the description carries full burden. It claims 'all cards' but fails to disclose pagination (page/per_page), whether archived cards are included, or that iteration is needed to fetch truly all cards. This is a significant gap for a list operation.

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

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

The description is a single six-word sentence with no superfluous content, directly front-loading the core action and resource.

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

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

The description is too thin for a paginated list tool. It fails to clarify what 'belonging to an epic' means (direct cards vs all descendants), does not mention pagination defaults, and provides no context beyond the tool name. The output schema exists but does not compensate for missing usage context.

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 provides no explanation of epic_id, page, or per_page. The phrase 'all cards' even contradicts the need for pagination, leaving parameter semantics entirely unspecified.

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 'List all cards belonging to an epic' uses a specific verb and resource, clearly distinguishing this tool from generic list_cards or list_project_cards by the epic scope.

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?

Implies usage when needing cards for a specific epic, but does not explicitly state alternatives or exclusions (e.g., use list_cards for all cards). No when-not-to-use guidance is provided.

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

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

With no annotations, the description carries the full burden. It discloses that state and status are filterable fields and provides their valid values, which is additional context beyond the schema. However, it does not mention pagination, optionality, or return behavior, leaving some gaps.

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

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

The description is extremely concise, with two short sentences (or fragments) that state purpose and filter options without unnecessary words. It is front-loaded with the main action.

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

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

The description provides the essential purpose and filter values. Given the presence of an output schema and the simplicity of the list operation, it is sufficiently complete, though it lacks explicit mention of pagination and optional filter semantics, which are inferable from the schema.

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 description adds meaning for the 'state' and 'status' parameters by listing acceptable values, which is not present in the schema (no enums). It does not explain 'page' or 'per_page' behavior, and the required 'project_id' is only implicitly referenced via 'for a project'. Since schema description coverage is 0%, this partial compensation yields a score of 3.

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

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

The description clearly states the tool lists epics for a project, using the verb 'list' and resource 'epics'. It distinguishes from sibling tools like get_epic (single epic) and list_epic_cards (lists cards within an epic).

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

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

The description implies usage for listing epics but does not provide explicit guidance on when to use it versus alternatives such as get_epic or list_epic_cards. There are no exclusions or alternative references.

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

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

With no annotations, the description carries the full burden of disclosing behavioral traits, but it does not state that the operation is read-only, does not mention pagination behavior (despite page/per_page parameters), and gives no indication of error conditions or side effects. This leaves the agent to infer safety, which is a significant gap for a mutation-prone environment.

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

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

The description is a single, concise sentence that is front-loaded with the action and resource. It is appropriately sized for the simplicity of the tool and contains no fluff or repetition.

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?

While an output schema exists (so return values need not be described), the description lacks essential context: no mention of pagination, parameter semantics, or operational constraints. Given the 0% schema coverage and missing annotations, the description is not complete enough for an agent to use the tool correctly without additional assumptions.

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

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

The schema description coverage is 0%, meaning the description must explain parameters, but it only hints at project_id through 'for a project' and completely omits the page and per_page parameters. The agent cannot understand pagination or required inputs from the description alone.

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 ('list') with a clear resource ('labels') and scope ('for a project'), which immediately distinguishes it from sibling tools like create_label or list_cards. It is precise and unambiguous.

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

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

The description implies when to use it (when you need labels for a project) but provides no explicit guidance on alternatives, prerequisites, or exclusions. It is adequate but minimal, with no mention of when not to use it or how it differs from related tools like create_label.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'filtering and ordering' but only gives details for three filter parameters, leaving pagination, default ordering, state filtering, and other behaviors unexplained. It does not disclose rate limits, authentication needs, or the read-only nature explicitly, though 'List' implies read.

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 extremely concise and front-loaded with the primary purpose in the first sentence. The three parameter notes are each a single line, adding value without redundancy. Every sentence earns its place with clear, focused 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?

Despite the presence of an output schema, the description is incomplete for a tool with 12 parameters and no annotations. It fails to explain the majority of parameters, including pagination, ordering choices, state filtering, and search, leaving users to guess their semantics. The description covers only a fraction of the tool's capabilities.

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 by explaining parameter meanings. It does explain three parameters (number, assignee_ids, label_names) with concrete examples, but nine other parameters remain entirely unexplained, including page, per_page, state, order_by, order_direction, search_key, category_name, and workspace_id. This partial coverage is insufficient for a tool with 12 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?

The description clearly states the tool's function with a specific verb ('List') and resource ('cards'), and scopes it to 'a specific project', distinguishing it from sibling tools like list_cards, list_epic_cards, and list_triage_cards. The inclusion of 'filtering and ordering' further defines its purpose.

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

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

The description clearly implies use for listing cards within a specific project, providing context for when it should be used over the broader list_cards tool. However, it does not explicitly mention alternatives or state when not to use it, so it stops short of full 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?

Annotations are absent, so the description must carry behavioral disclosure. It only says 'List all members' without addressing pagination, read-only status, permissions, or that page/per_page parameters may limit results. The term 'all' is ambiguous given the pagination 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?

The description is a single, clear sentence that front-loads the purpose with no filler or redundancy. Every word is necessary and useful.

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

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

For a simple list tool with an output schema, this is minimally adequate. However, it omits pagination behavior and any context about what 'all members' means when page/per_page defaults apply. With no annotations, more behavioral detail would improve completeness.

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

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

Schema description coverage is 0%, and the description does not explain parameters. It indirectly references 'project' for project_id but leaves page and per_page semantics entirely to inference from names and defaults. The description adds minimal value beyond the schema.

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

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

The description uses a specific verb ('List') and resource ('members of a project'), clearly defining the tool's action and scope. It distinguishes from sibling tools like list_account_members by scoping to project membership.

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 usage is implied by the description: use when you need all members of a project. However, there is no explicit guidance on when to choose this over alternatives like list_account_members, and no exclusions or prerequisites are 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 are provided, and the description adds no behavioral details beyond the basic listing action. It does not disclose pagination behavior, ordering, access scope, or any side effects, so the agent must infer these from 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?

The description is extremely concise: two short sentences that immediately state the action and the optional filter. Every word earns its place, with no filler or repetition.

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

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

The output schema exists, so return values are covered elsewhere, and the tool is a simple read/list operation. However, the description omits pagination behavior and scope details, which are relevant given the page/per_page parameters. It is minimally sufficient but has 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?

The input schema has 0% description coverage, so the description must compensate. It only mentions account_id and does not explain page or per_page semantics, their defaults, or how they affect the response. The parameter names are somewhat self-explanatory, but the description provides minimal 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 clearly states the tool lists all projects, using a specific verb and resource. It distinguishes from singular 'get_project' and other list tools by resource, and mentions optional account_id filtering.

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

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

The description provides clear context: use this to list all projects, with optional filtering by account_id. It does not explicitly name alternatives or exclusions, but the list-vs-get distinction is evident from sibling tool names.

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. It conveys a read-only listing operation and scopes to 'connected' sources. However, it does not mention pagination behavior, auth requirements, or any potential side effects, though none are expected for a list.

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 resource clearly in nine 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?

Given the tool's simplicity, an output schema exists, and the description adequately states the purpose. However, it lacks any mention of pagination parameters or usage context, making it minimally complete but not comprehensive.

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 has two parameters (page, per_page) with 0% description coverage, and the tool description provides no explanation of these parameters. The description fails to compensate for the lack of schema descriptions, leaving parameter semantics to inference from names and defaults.

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

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

The description clearly states the tool lists all connected GitHub repositories (sources), using a specific verb and resource. This distinguishes it from sibling list tools like list_accounts and list_projects.

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

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

The description implies usage for retrieving connected GitHub repositories, but does not explicitly contrast with alternatives or state when not to use it. While the purpose is self-evident, there is no guidance beyond the core 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 burden for behavioral disclosure, but it only states the basic action and a filter option. It does not mention pagination behavior, default state behavior (e.g., whether omitting state returns all sprints), ordering, or any access requirements. This leaves significant ambiguity for a read/list operation.

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

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

The description is very short and front-loaded, but the second fragment 'state: open/closed.' is grammatically awkward and reads more like a note than a complete sentence. It is concise, but the lack of structure slightly reduces clarity.

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?

An output schema exists, so return values are covered, but the description still fails to address pagination parameters and the workspace_id requirement. For a tool with 4 parameters and 0% schema description coverage, this is insufficient contextual guidance. The presence of sibling get_sprint also suggests a need for usage distinction that is not provided.

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 adds meaning for the 'state' parameter by specifying open/closed, but workspace_id, page, and per_page are not explained beyond their schema definitions. The coverage is insufficient for an agent to confidently construct parameter values.

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

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

The description clearly states the tool lists sprints for a workspace, using a specific verb and resource. It also mentions the state filter (open/closed), and the purpose is distinct from sibling tools like get_sprint, create_sprint, and update_sprint.

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 is provided about when to use list_sprints versus alternatives like get_sprint. The description does not mention any exclusions, prerequisites, or context that would help an agent decide between this tool and similar list tools (e.g., list_projects, list_cards).

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 disclose behavioral traits. It only lists filter value sets but does not state read-only behavior, pagination, return structure, or side effects. The existence of an output schema partially mitigates return format, but the description itself lacks transparency about operational behavior.

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

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

The description is concise and front-loaded with the core purpose, followed by terse parameter value lists. There is no filler, though the structure could be improved by grouping parameters for readability.

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 7 parameters and an output schema, the description covers essential filters but lacks pagination semantics and assignee_id clarification. The output schema likely documents return values, so the incomplete parameter guidance lowers completeness but not drastically for a simple list operation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains valid values for state, status, and priority, but omits the required project_id, as well as assignee_id, page, and per_page. This leaves the majority of parameters semantically 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 clearly states the action ('List') and the resource ('tickets for a project'), which distinctly differentiates it from sibling tools like get_ticket (single ticket) and list_cards (different entity). It also enumerates accepted filter domains (state, status, priority), reinforcing the tool's scope.

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

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

The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It implies usage for listing tickets but does not explicitly distinguish it from other list tools (e.g., list_cards or list_epics) or mention context like required project_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?

With no annotations, the description carries the full burden. It discloses the key behavioral filter (triage = unassigned to any workspace column), which adds useful context beyond the name. However, it does not mention potential side effects (likely none), permission requirements, or output behavior like pagination, leaving room for more transparency.

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

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

The description is a single sentence that is concise and front-loaded with the action and object. Every word adds meaning, and there is no filler or redundant content.

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

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

This is a simple list tool with one parameter, an output schema exists (so return values are documented), and the description clarifies the scope in comparison to siblings. The description is adequate for the tool's complexity, though it could mention whether archived cards are included or if there are any limits.

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

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

The schema provides only 'project_id' as an integer with no description (0% coverage). The description adds context by linking this ID to 'a project's triage', which clarifies the parameter's role. Yet it does not specify the required nature or any formatting, so compensation is minimal but sufficient for a simple ID.

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 'List' and identifies the resource as 'cards in a project's triage', with a clarifying parenthetical 'unassigned to any workspace column'. This clearly distinguishes it from sibling tools like list_cards and list_project_cards by specifying the triage filter.

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

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

The description implies usage for viewing unassigned cards in a project, but does not explicitly discuss when to use this tool versus alternatives such as list_cards or list_project_cards. No exclusions or alternative references are provided.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It discloses the list operation and the optional filter, but omits mention of pagination behavior despite the page and per_page parameters in the schema, and does not explain whether 'all' means a single page or all pages. No information is provided about authentication requirements, rate limits, or ordering.

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

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

The description is two short sentences, front-loading the main purpose and adding the optional filter in the second sentence. No filler or redundant language exists.

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

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

Given the tool's low complexity and the presence of an output schema, the description captures the core operation and the main filter. However, it is incomplete regarding pagination semantics, has no usage guidance versus sibling tools, and lacks any behavioral notes, making it minimally sufficient.

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

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

The schema has no field descriptions (0% coverage), so the description is the only source for parameter meaning beyond types/defaults. It explains project_id as a filter, but does not explain page or per_page, leaving their purpose implied by the schema defaults. This is partial compensation for the low schema coverage.

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

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

The description clearly identifies the tool as a list operation for workspaces, using the verb 'list' and the resource 'workspaces', and clarifies that workspaces are Kanban boards. This distinguishes it from single-item retrieval tools like get_workspace and from creation tools like create_workspace, though it doesn't explicitly name siblings. The wording is specific and unambiguous.

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

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

The description provides the context of listing all workspaces and optionally filtering by project_id, which implies when to use the tool. However, it does not explicitly state when to prefer this over get_workspace for a single workspace or how it relates to list_projects. No exclusions or alternative tool names are mentioned, so guidance is only implicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention side effects (e.g., removal from previous column, index reordering), permission requirements, or error conditions. The only extra context (destination_type semantics) is more about parameter behavior than tool behavior.

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

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

The description is highly concise: two sentences plus a brief parameter note. It is front-loaded with the main action and includes only essential conditional detail, with no redundant phrasing.

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?

As a mutation tool with 5 parameters and no annotations, the description is incomplete. It omits position semantics, the parameter mapping for project triage, and behavioral consequences. While an output schema exists, the description still leaves key operational details unclear.

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%, so the description must compensate. It adds meaning to destination_type and the conditional requirement for workspace_id/category_name for 'category' moves. However, it does not explain the meaning of 'position' or which parameters are needed for the 'project' triage destination, leaving gaps.

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

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

The description clearly states the tool moves a card to a board column or project triage, using a specific verb and resource. It distinguishes from sibling card tools (archive, update, create) by describing the destination types, making the purpose unambiguous.

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

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

The description provides clear context for usage by explaining the two destination_type options and the conditional requirement for category moves (workspace_id and category_name). However, it does not explicitly contrast with alternative tools like update_card or archive_card, so 'when not to use' is missing.

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

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

With no annotations provided, the description carries the full burden and adds value by disclosing partial-update semantics ('Only provided fields are changed') and giving concrete constraints for 'state' and 'priority' beyond the schema. It does not mention permissions, error behavior, or null field semantics, but the added details are useful.

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 extremely concise, consisting of two short sentences that front-load the primary purpose and then provide key field constraints. No wasted words, and the structure is clear and scannable.

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

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

For a tool with 12 parameters and no annotations, the description covers only a subset of the semantics (state and priority). It lacks guidance on how to use other fields, especially null handling, and does not differentiate from related tools like move_card or archive_card. Though an output schema exists, it doesn't compensate for these 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 schema has 0% description coverage, so the description must compensate. It does explain 'state' and 'priority' with allowed values, but leaves the other 10 parameters without any additional meaning. The global 'only provided fields are changed' partially clarifies behavior, but the distinction between omitted and null fields remains ambiguous.

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

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

The description clearly states the tool's function with a specific verb and resource: 'Update an existing card.' It also notes 'Only provided fields are changed,' which distinguishes it from create, move, or archive operations. This makes its purpose unambiguous and distinct from sibling tools.

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

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

The description implies usage for modifying card attributes but does not explicitly state when to use this tool versus alternatives like move_card or archive_card. There are no exclusions or alternative tool references, so the guidance is only implicit.

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

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

Annotations are absent, so the description must disclose behavioral traits, but it only states the action. It does not mention that 'body' replaces the entire comment text, whether the update is reversible, permission requirements, or error handling for invalid card_id/comment_id. This is a significant transparency gap for a mutation tool.

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

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

The description is a single, front-loaded sentence with no wasted words: 'Update an existing comment on a card.' It is appropriately concise, though the brevity contributes to under-specification 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?

With no annotations and a minimal description, the tool lacks essential operational context: what 'body' means, whether partial updates are allowed, and edge-case behavior. The presence of an output schema covers return values, but the description is still too sparse for reliable invocation.

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

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

Schema description coverage is 0%, and the description adds no explanation of body, card_id, or comment_id semantics beyond their names. The description does not compensate for the missing schema descriptions, leaving the agent to infer that 'body' is the new text and that the IDs identify the target.

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

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

The description uses the specific verb 'Update' with the resource 'existing comment' and the scope 'on a card'. This clearly differentiates the tool from sibling tools like create_card_comment, delete_card_comment, and list_card_comments by indicating modification of an existing entity.

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 explicit when-to-use guidance or alternatives are provided. The word 'existing' implies this is not for creating or deleting, but there is no mention of when to choose this over create_card_comment or delete_card_comment, nor any prerequisites such as needing an existing comment_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?

With no annotations, the description must fully disclose behavioral traits. It provides allowed values for state and status, which is helpful, but does not explain update semantics (e.g., whether null fields are ignored or set to null), required permissions, or side effects. This leaves significant ambiguity for an update operation.

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

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

The description is one concise sentence, front-loaded with 'Update an epic' and compactly lists the valid values for state and status. There is no fluff or redundancy, making it efficient and easy to parse.

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

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

The tool has 11 parameters, 2 of which are required, yet the description only addresses two. It omits vital usage context like partial vs. full updates, the role of required fields, and the meaning of ambiguous parameters. The presence of an output schema does not mitigate the lack of parameter documentation.

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's enum values for state and status add some meaning. However, the other nine parameters (e.g., track_cards, assignee_id, due_on) are undocumented in both schema and description. The description fails to compensate for the lack of parameter descriptions.

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

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

The description clearly states the tool updates an epic, identifying the specific resource and action. It distinguishes from create_epic and get_epic by using 'update', though it doesn't explicitly contrast with sibling update tools like update_project or update_sprint.

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 is provided on when to use this tool versus alternatives. There is no mention of when updating is appropriate (e.g., after fetching an epic), no conditions that would favor other tools, and no warnings about when not to use it.

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

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

With no annotations, the description carries the burden. It discloses the color format and that name is fetched from the current project if omitted, which is useful. However, it does not mention permissions, reversibility, or effects on unspecified fields.

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 concise sentences, front-loaded with purpose, and each sentence provides useful information. The color note is terse yet clear, and 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?

For a six-parameter update tool with no annotations and no schema descriptions, the description covers only a subset of parameters. The existence of an output schema helps, but the behavior around partial updates and the boolean flags remains unclear.

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 explains the color format and the name-fetching behavior, but leaves auto_add_github_users, should_use_fibonacci_scale, and description without any added meaning beyond their 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?

The description clearly states the tool updates a project's name, description, or settings, using a specific verb and resource. It distinguishes from sibling tools like create_project and get_project by its update focus.

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 explicit guidance on when to use this tool vs alternatives, but the name and context imply it is for modifying existing projects. The behavioral note about Zube requiring name adds context but not exclusions or alternatives.

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

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

With no annotations provided, the description must carry the full burden of disclosing behavioral traits. It only mentions the allowed values for 'state' ('open' or 'closed') but does not explain mutation semantics, permission requirements, or the effect on existing sprint fields.

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 very concise, consisting of two short sentences. It is economical but could include more useful detail without becoming bloated, so the conciseness is slightly impaired by under-specification.

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?

Despite an output schema existing, the description is inadequate for a 7-parameter mutation tool with no annotations. It omits update semantics (partial vs full), field defaults, and any prerequisites, making it insufficient for correct tool selection and invocation.

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

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

Schema coverage is 0%, so the description must compensate for the lacking parameter documentation. It explains only the 'state' parameter's allowed values, while leaving 'title', 'end_date', 'start_date', 'description', 'sprint_id', and 'workspace_id' unaddressed.

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

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

The description clearly states the tool's action ('Update a sprint') and identifies the resource. It distinguishes from sibling update tools by naming the specific entity, though it doesn't enumerate all updatable fields, only mentioning 'state'.

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 is provided on when to use this tool versus other update tools, nor are prerequisites or typical workflows mentioned. The description only states what the tool does, not when it should be chosen.

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?

Since no annotations are present, the description must disclose behavioral traits. It only lists valid state and status values but does not describe side effects, required permissions, validation rules, or what happens to other fields.

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 brief with two sentences, front-loading the primary purpose. No filler or redundant 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?

With 13 parameters, no annotations, and no parameter descriptions, the description covers only a small fraction of the tool's scope. Missing details on required fields (project_id, ticket_id), output behavior, and field interactions make it insufficient for reliable invocation.

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

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

Schema description coverage is 0%, so the description must compensate for 13 parameters. It only documents allowed values for state and status, leaving the other 11 parameters (title, due_on, priority, etc.) 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 clearly states 'Update a ticket' with a specific verb and resource. It also enumerates allowed values for state and status, distinguishing this update operation from create/get ticket 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?

No guidance is provided on when to use this tool versus alternatives like create_ticket, update_card, or update_project. The description only defines what the tool does without specifying use cases or exclusions.

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