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

Annotations already state readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the mutation profile is known. The description adds only 'for a project' and says nothing an agent needs for a non-idempotent create: duplicate-name behavior, permission requirements, or what happens on failure.

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

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

One short, front-loaded sentence with no waste. It is efficient but borders on under-specified rather than tight.

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?

Only 'name' is required per the schema, yet the description implies project scoping is inherent to the operation, leaving ambiguity about whether projectId/projectKey are mandatory and which to use (ID vs key). For a create tool with no output schema, that ambiguity should be resolved in the description.

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 100%, so the schema fully documents name, projectId, and projectKey. The phrase 'for a project' gestures at the project scoping parameters but adds no syntax, format, or requiredness guidance beyond the schema. Baseline 3 applies.

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

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

A clear verb+resource statement: creates a category, scoped to a project. It does not distinguish itself from the sibling get_categories or explain how categories relate to issues/projects, 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?

No indication of when to create a category versus reading existing ones with get_categories, and no prerequisites or preconditions (e.g., does the category already exist?). The agent must infer usage entirely.

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 already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=false, so the mutation profile is covered. The description adds nothing beyond that — it doesn't mention ordering behavior (addLast), parent/child nesting implications, or what happens if required content is omitted.

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

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

One short, front-loaded sentence with no filler. Its brevity is appropriate in form, though the space saved is not spent on any useful 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 6-parameter creation tool with no output schema, the description should explain document hierarchy behavior (parentId vs projectId) and what is returned on success. None of that is present, leaving the agent to infer nontrivial semantics from parameter names alone.

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 100%, so all six parameters including projectId, parentId, and addLast are documented in the schema itself. The description adds no supplementary meaning about how parameters interact (e.g., parentId vs projectId placement). Baseline 3 applies when the schema does the heavy lifting.

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

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

The description names a specific verb ('Adds') and resource ('document') scoped to a project, so an agent knows the operation. However, it offers no differentiation from siblings like add_wiki or add_issue, which also create content inside a 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?

There is no guidance on when to use this tool versus add_wiki or add_issue, and no prerequisites or exclusions are mentioned. The agent must infer usage purely from the name and the surrounding sibling list.

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 already declare destructiveHint=false, idempotentHint=false, and readOnlyHint=false, so the description carries a lighter burden. It adds nothing beyond them — notably it omits that non-idempotency means repeated calls create duplicate issues, and it says nothing about required permissions or side effects (notifications to notifiedUserId, attachments).

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

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

A single front-loaded sentence with no filler, which is good structure. But it is under-specified rather than concise: for a 17-parameter creation tool it leaves the agent to infer nearly everything.

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 17 parameters, four of them opaque numeric IDs, and no output schema, the description should explain prerequisites and what comes back (e.g. the new issue ID). Instead it restates the title and nothing more; the full disclosure burden falls on the schema alone.

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

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

Schema description coverage is 100% across all 17 parameters, so baseline 3 applies. The description contributes no additional meaning about required IDs, date formats, or how customFields values map to field types beyond what the schema already documents.

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

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

States a specific verb and resource ('Creates a new issue') plus the scoping container ('specified project'), so the agent knows exactly what the tool does. It stops short of differentiating itself from siblings like add_issue_comment or update_issue, but the core action is unambiguous.

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

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

No guidance on when to use this versus update_issue, add_issue_comment, or add_related_issue. Nothing tells the agent that issueTypeId and priorityId must first be discovered via get_issue_types and get_priorities, which is the main practical prerequisite for a successful call.

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

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

Annotations already declare the mutation semantics (readOnlyHint=false, destructiveHint=false, non-idempotent, closed-world), and the description is consistent with them, so there is no contradiction. But it adds nothing beyond that boilerplate: it doesn't say whether the comment is attributed to the caller, whether attachment IDs must be pre-uploaded, or what notification side effects the notifiedUserId list triggers.

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

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

A single short sentence with no filler and the action front-loaded, so there is nothing wasteful. But the brevity comes at the cost of the guidance that would make the sentence earn its place for a five-parameter mutation 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?

Annotations cover the safety profile and the schema fully documents all five params, so much of the burden is already carried. Still, for a write tool with no output schema and an issueId/issueKey ambiguity, the description is thinner than ideal — it never addresses identifier choice or the attach/notify behavior.

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

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

Schema coverage is 100%, so the schema documents each parameter and the baseline is 3. The description adds nothing about the key ambiguity left in the schema: only content is required, yet the tool must be disambiguated by either issueId or issueKey, and the description never says which to supply or whether they are interchangeable.

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

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

States a concrete verb and resource ("Adds a comment to an issue"), so the action is unambiguous. However, it does nothing to separate itself from near-identical siblings such as add_pull_request_comment and update_issue_comment, leaving the agent to infer the difference from the names alone.

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

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

There is no guidance on when to use this versus update_issue_comment or add_pull_request_comment, and no mention of prerequisites (e.g., that an issue identifier must be supplied). The agent gets a purpose but no selection criteria.

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 already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — it doesn't mention that repeated calls with the same key may fail, what gets created (default settings), or auth requirements 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?

A single front-loaded sentence with zero waste, though it borders on under-specification rather than tightness. Nothing is padded, but there is also almost nothing there.

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 creation tool with no output schema, the description leaves key gaps: it doesn't say what is returned (e.g., the new project's identifier needed for subsequent calls) or what constraints apply to the required key. Annotations cover the safety profile only, so the description should carry more of the load here.

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

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

Schema description coverage is 100%, so all six parameters including the required name/key pair and defaults for chartEnabled, subtaskingEnabled, and textFormattingRule are already documented. The description contributes no additional parameter meaning, which is the expected baseline when the schema does the heavy lifting.

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

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

The description gives a specific verb and resource ("Creates a new project"), which unambiguously tells the agent this is the create operation for projects. It doesn't explicitly contrast with update_project or get_project_list, but the name plus phrasing already make the distinction obvious.

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

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

There is no guidance on when to use this versus alternatives, no prerequisites (permissions, existing project keys, space selection), and no note about what to do if the key already exists. The agent must infer everything from the one-line purpose.

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 already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, so safety and idempotency are covered structurally. The description adds nothing on top: it does not mention required permissions, what happens when branch/base are invalid, whether duplicate PRs error out, or what the issueId linkage does. With 11 parameters and a mutation, this is a thin description.

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

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

A single short sentence with no wasted words, but it is under-specified rather than genuinely concise. Front-loading is trivial here because there is only one clause.

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

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

For an 11-parameter mutation with no output schema, the description omits the return value, the meaning of the two required branch parameters versus the optional repo/project identifiers, and the effect of linking an issue. An agent must reconstruct all of this from the schema alone.

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

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

Schema description coverage is 100%, so every parameter is documented inline (including the base/branch distinction and the repoId vs repoName vs projectId/projectKey alternatives). The description contributes no additional parameter meaning, which is acceptable at baseline 3 given full 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 'Creates a new pull request' merely restates the tool name add_pull_request in prose, adding no specificity about scope, target system, or outcome. It does differentiate implicitly from update_pull_request/get_pull_request through the verb 'creates', but that distinction comes from the name itself, not the description.

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

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

No guidance on when to use this versus update_pull_request or when a PR is the right artifact versus an issue comment or linked issue. No prerequisites, no context about which repo/project parameters are needed in which combination.

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?

The annotations already declare this as a non-read-only, non-idempotent, non-destructive, closed-world operation, and the description's "Adds" is consistent with that. However, the description adds no further behavioral context such as notification effects or permission requirements.

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

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

The description is a single front-loaded sentence with no wasted words. It is appropriately sized for the tool's apparent simplicity.

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 schema fully documents the parameters and the annotations cover safety behavior, so the description is minimally sufficient. It does not explain the notification parameter's effect or clarify when this should be used instead of related comment tools, leaving some contextual gaps.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the input schema. The description adds no parameter-specific meaning beyond what the schema provides, making the baseline score of 3 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 states a specific verb and resource: "Adds a comment to a pull request." This clearly distinguishes it from sibling operations such as get_pull_request_comments, update_pull_request_comment, and add_issue_comment.

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 explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The intended use is only implied by the tool name and one-line description.

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

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

Annotations already disclose that this is a non-destructive, non-idempotent mutation; the description adds nothing beyond that. It does not say whether adding an existing relation errors or is silently ignored, whether the relationship is directional, or what the response contains — all of which matter for a mutation with idempotentHint=false.

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

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

One short, front-loaded sentence with no filler. The problem is under-specification rather than verbosity, so the structure itself is efficient.

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

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

For a mutation tool with three parameters, no output schema, and a sibling that reverses the operation, the description is too thin. It omits directionality, duplicate-handling, and any indication of what the agent gets back, leaving key behavioral questions unanswered.

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 100%, so the baseline is 3. The description adds no meaning about issueId vs. issueKey (both optional alternatives) or why targetIssueId is the only required parameter, so it neither helps nor hurts 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 names a specific verb and resource ('Relates an issue to another issue'), but it never clarifies the directionality of the relationship — which issue is the source and which is the target. Sibling tools get_related_issues and remove_related_issue make the operation recognizable, but the description does not differentiate or explain the asymmetry.

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 about when to use this instead of get_related_issues or remove_related_issue, nor any prerequisites (e.g., permissions, valid issue states). The agent must infer usage entirely from the name and schema.

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

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

Annotations already declare readOnlyHint=false and idempotentHint=false, so an agent knows this writes and is not idempotent, yet the description never warns that repeated calls may create duplicate milestones nor describes permission requirements. For a non-idempotent mutation with no output schema, the description adds no behavioral context beyond the annotations.

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

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

A single front-loaded sentence with no filler, but it is under-specified rather than economical; there is room for one more sentence of routing guidance that would earn 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 six-parameter, non-idempotent creation tool with no output schema, the description omits how the project is scoped (projectId vs projectKey), what happens on name collision, and what is returned. That is more than an agent can safely infer.

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

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

Schema description coverage is 100% with six documented parameters, so the schema carries the semantics and baseline 3 applies. The tool description provides no additional meaning, such as when to use projectId versus projectKey or expected date formats.

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 phrase 'Creates a new version milestone' names a verb and a resource, so the basic action is legible, but it adds nothing beyond the tool name expanded into a sentence and never distinguishes this from update_version_milestone or get_version_milestone_list. It sits at the line between a clear purpose and a tautology.

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

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

There is no statement of when to use this tool versus its siblings, no prerequisite (e.g. a project must be selected first), and no mention of the update/get counterparts in the sibling list. Usage is only inferable from the verb 'creates'.

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 already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the safety profile is covered and the description does not contradict it. However, the description adds no behavioral context beyond the annotations — it does not say that the watch is per-current-user, what happens if the issue is already watched (non-idempotent implies duplication), or whether the owner gets notifications.

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

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

A single clause with the verb front-loaded and zero filler. It is well structured, though its brevity stems partly from under-specification rather than from disciplined editing.

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

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

With only two parameters, no output schema, and annotations covering safety, the definition is nearly minimal. It still omits what a "watch" is in this product (a subscription to an issue's notifications), who the watcher is, and what a successful response looks like — gaps that matter for a non-idempotent create 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 100%, with both issueIdOrKey and note documented in the schema (including ID/key format and the note's optionality), so this is the baseline case. The description adds nothing about parameter meaning, which is acceptable but not additive.

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

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

States a specific verb and resource ("Adds a new watch") plus the scope ("to an issue"), so an agent can tell this is a watch-creation action rather than a generic write. It does not differentiate itself from the very close siblings update_watching, delete_watching, or add_issue, which would be needed for a 5.

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

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

There is no when-to-use guidance and no mention of alternatives, despite three sibling tools operating on the same watch resource (get_watching_list_items, update_watching, delete_watching). The agent is left to infer that this is the create path and nothing else.

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 already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, so the mutation profile is covered. The description adds nothing beyond that—no note on email notification side effects (the mailNotify param implies one) or whether duplicates are created.

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

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

A single short sentence with zero waste, but it is under-specified rather than concise—there is no front-loaded scope or key constraint to anchor the call.

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 write tool with no output schema, the description says nothing about the returned page, whether the email notification is triggered by default, or what happens on name collision. Annotations carry the safety profile, but the behavioral context is thin.

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

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

Schema description coverage is 100%, so all four parameters including mailNotify are already documented in the schema. The description adds no parameter meaning, which meets the baseline 3 for high-coverage schemas.

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

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

States a specific verb ('Creates') and resource ('wiki page'), so the action is identifiable. But it does nothing to distinguish itself from siblings like update_wiki or add_document, and reads close to a restatement of the tool name.

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

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

No indication of when to use this versus update_wiki, get_wiki, or add_document, and no prerequisites (project scope, required permissions) are mentioned. The agent must infer usage entirely.

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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it says nothing about how the count is computed, whether filters combine with AND semantics, or what the response looks like (no output schema).

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

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

A single sentence with no waste, but its brevity reflects under-specification rather than disciplined concision. There is nothing to front-load because nothing was said.

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 21 optional filter parameters and no output schema, the description leaves critical gaps: it never explains that the parameters are filters narrowing the count, nor describes the return shape or how an empty filter set behaves. This is inadequate for the tool's 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 description coverage is 100% across all 21 parameters, so the schema carries the full burden and baseline 3 applies. The description contributes no additional meaning about how filters, date ranges, or custom fields affect the count.

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?

"Returns count of issues" states a verb and resource, but it essentially restates the tool name (count_issues) and gives no scope or differentiation from the sibling get_issues. An agent can infer it counts rather than lists, but nothing more.

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 instead of get_issues, or what tradeoffs apply (e.g., use count for totals/pagination, get_issues for details). The agent must infer usage from the name alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is fully covered structurally. The description adds nothing beyond the purpose statement — it does not say what the count represents (total vs unread vs filtered), nor how the two boolean flags change the result, nor the response shape.

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

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

A single front-loaded sentence with no waste. It is appropriately sized, though the terseness leaves the description thin rather than dense with useful 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 two-parameter counting tool with no output schema, the description should at minimum clarify what is being counted (unread notifications by default, presumably) and what happens with the boolean filters. Those gaps mean an agent can invoke it but may misinterpret the returned number.

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

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

Schema description coverage is 100% and both required booleans are documented in the schema, so the baseline of 3 applies. The description contributes no additional meaning about how alreadyRead and resourceAlreadyRead interact to shape the count.

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

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

States a specific verb and resource ('Returns count of notifications'), which is clear enough to distinguish a counting operation from a listing operation. However, it never contrasts with get_notifications or reset_unread_notification_count, so the sibling distinction is left implicit.

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

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

No guidance on when to use this versus get_notifications (which presumably returns the notifications themselves) or reset_unread_notification_count. The agent must infer which of the three notification tools produces a count.

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 already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered structurally; the description adds nothing beyond that — no statement that deletion is permanent, whether comments/attachments go with it, or what permissions are needed. It does not contradict the annotations, but it contributes zero behavioral context.

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

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

It is a three-word sentence with no waste, but the brevity is under-specification rather than efficiency: there is no front-loaded scope, consequence, or identifier guidance an agent could act on.

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

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

For a destructive, irreversible mutation the description is too thin. Critically, zero parameters are marked required and the description says nothing about supplying issueId or issueKey, leaving the call signature ambiguous despite a rich sibling set and no output 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?

Schema description coverage is 100% and both parameters (issueId, issueKey) are documented with examples, so baseline 3 applies. The description adds no meaning beyond the schema, notably nothing about whether one or both identifiers are needed.

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

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

"Deletes an issue" restates the tool name (delete_issue) without adding scope or specificity. It does not distinguish this from sibling destructive tools (delete_watching, delete_version, remove_related_issue), nor say whether deletion is permanent or what an issue encompasses.

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 when-to-use guidance, no prerequisites, and no named alternative (e.g., closing vs. deleting, or using remove_related_issue instead). The agent must infer everything from the name alone.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds nothing beyond that — no mention of irreversibility, cascade effects on issues linked to the version, or required permissions. It merely restates the name.

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

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

A single, front-loaded sentence with no wasted words. It is appropriately sized for the amount of information it actually conveys, though that information is thin.

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

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

For a destructive mutation tool, the definition leaves critical gaps: it doesn't explain whether projectId or projectKey is required to scope the deletion (only id is required in the schema), nor what happens to entities attached to the deleted version. With no output schema and annotations carrying only the safety profile, the description should do more.

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 100%, so each of id, projectId, and projectKey is already documented with examples. The description adds no parameter meaning, which is acceptable given full schema coverage but warrants only the baseline score.

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

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

States a specific verb and resource ('Deletes a version from a project'), but 'version' is ambiguous given sibling tools like get_version_milestone_list and update_version_milestone; the description never clarifies whether it deletes a version milestone or a project version. An agent can't confidently distinguish this from version-milestone operations.

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 when-to-use or when-not-to-use guidance, and no alternatives named. It also doesn't state prerequisites (e.g., whether the version must be unreleased or empty), which matters for a destructive operation.

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 already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered structurally. The description adds nothing beyond this — no statement about permanence, whether the underlying issue is affected, or authorization requirements — so it contributes essentially no behavioral context.

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

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

One short sentence with zero padding and the key information front-loaded. It is terse rather than bloated; the issue is under-specification, not verbosity.

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 delete with full annotations and no output schema, the definition is minimally sufficient to invoke correctly. It is missing the practically important detail of where a watchId comes from and what happens to the watch afterward.

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 100% for the single watchId parameter, and the schema description ('Watch ID to delete') already explains it. The description adds no format, source, or lookup guidance, which is acceptable but not additive.

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

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

States a specific verb and resource ('Deletes a watch from an issue') so the operation is unambiguous. It does not differentiate itself from siblings like update_watching or mark_watching_as_read, but the verb alone distinguishes it well enough.

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

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

There is no guidance on when to use this versus update_watching, mark_watching_as_read, or how to obtain a watchId (e.g. via get_watching_list_items). The agent must infer everything about selection and preconditions 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only the project scoping, and says nothing about result ordering, pagination, or what happens when neither identifier is provided.

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

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

A single front-loaded sentence with zero filler. It is efficient rather than padded; the only criticism is that brevity here reflects thin content rather than tight editing.

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

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

For a read-only, zero-required-parameter list tool with fully described parameters and no output schema, the description is minimally adequate. It still omits return shape, ordering, and how the two optional identifiers interact, which an agent would need to call it confidently.

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

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

Schema description coverage is 100%, so both parameters are documented and the baseline is 3. The description does not clarify the relationship between projectId and projectKey (nor the apparent copy-paste error in projectKey's schema text), leaving that ambiguity 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?

States a concrete verb and resource ("Returns list of categories") and scopes it to a project, which is clear enough to distinguish from add_category. It stops short of differentiating itself from other read-only list siblings like get_priorities or get_custom_fields, so a 4 rather than 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 call this tool versus alternatives, no mention that add_category is the write counterpart, and no note on prerequisites or whether projectId or projectKey must be supplied. The agent must infer all of this.

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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds no behavioral context beyond restating that it returns a list; it does not mention pagination, permissions, or response shape.

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

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

The definition is a single front-loaded sentence with no filler. Every word contributes to identifying the resource and scope.

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

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

For a simple read-only list tool with rich annotations and full schema coverage, the description is adequate but leaves a subtle gap: both projectId and projectKey are optional in the schema, and the description does not clarify whether one is required or how the two identifiers relate.

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

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

Schema description coverage is 100%, so both projectId and projectKey are fully documented in the schema. The description adds no parameter-level semantics beyond implying that a project identifier is involved, which matches the baseline for high 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 gives a specific verb and resource: returns custom fields for a project. It is clear enough to distinguish from sibling tools like get_categories or get_priorities, although it does not explicitly name any sibling alternative.

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 phrase 'for a project'—the agent should call this when it needs a project's custom fields. However, there is no explicit when-to-use guidance, no mention of alternatives, and no 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is covered. The description adds behavior beyond that: content is truncated at `limit` and may be short of the requested size due to a server token limit, with continuation via `nextStart` — exactly the kind of operational detail annotations cannot carry.

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, no filler, with the return shape and the paging contract front-loaded. Every clause carries information an agent needs.

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

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

There is no output schema, and the description compensates by naming the returned fields (`plain`, `nextStart`) and explaining truncation. Only gap is that 'information about a document' beyond content is never enumerated.

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

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

Schema description coverage is 100% and each parameter already documents defaults and the nextStart hand-off, so the schema is doing the heavy lifting. The description reinforces the limit/start/nextStart relationship but adds little syntax or semantics not already in the schema.

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

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

States a specific verb+resource ('Gets information about a document') and immediately clarifies that the payload is plain-text content with paging. It is clear against list-oriented siblings like get_documents, but never explicitly distinguishes itself from get_document_tree or get_document_comments.

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 pagination loop is spelled out (call again with `start` set to `nextStart`), which is real usage guidance. However there is no statement of when to prefer this over get_documents, get_document_tree, or get_document_comments, or any prerequisite/exclusion.

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?

The annotations already declare readOnlyHint=true, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds one genuinely useful behavioral detail — that replies are nested in the result — but says nothing about ordering, pagination, or whether resolved comments are included in this 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?

One short sentence, front-loaded with the action and resource, with no filler. It is appropriately sized for a simple list tool, though slightly more detail could be folded in without bloat.

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

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

For a simple read-only, single-param tool with no output schema, this is close to sufficient, but an agent still lacks ordering, pagination, and empty-result behavior. Those are the main 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?

There is a single parameter with 100% schema description coverage, so the schema already documents documentId and the baseline is 3. The description adds no extra meaning, such as the expected ID format or where to obtain one.

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

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

States a concrete verb+resource: returns the comment list for a document. It also discloses the reply-nesting shape. No sibling is named, but the document scope cleanly separates it from get_issue_comments and get_pull_request_comments.

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 explicit when-to-use or when-not guidance, no mention of alternatives such as get_document or the *_comments siblings, and no stated prerequisites (e.g., needing read access or a valid documentId). Usage is only inferable 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond the basic operation: it does not mention pagination behavior, ordering, what a document represents, or whether results are scoped or limited.

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 arguably too terse, but it is not padded or poorly structured.

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

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

For a simple read-only list tool with full schema descriptions and annotations, the essentials are mostly covered. However, the description does not clarify how this differs from get_document_tree or get_document, nor does it mention pagination or multi-project behavior, leaving gaps for an agent choosing between similar 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 100%, so the schema already documents both offset and projectIds. The description's phrase 'in a project' loosely corresponds to projectIds but does not add syntax, array/multi-project semantics, or pagination guidance beyond what the schema provides. Baseline 3 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 states a clear verb and resource: 'Gets a list of documents.' However, it does not distinguish this from sibling tools like get_document_tree or get_document, and 'in a project' is slightly misleading because the required parameter is projectIds, an array supporting multiple 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?

It provides no guidance on when to use this tool versus alternatives such as get_document_tree or get_document. There are no exclusions, prerequisites, or context cues to help an agent choose correctly.

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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that – it does not say whether the tree is full-depth or truncated, whether it includes folders vs. pages, or anything about ordering or size of the response.

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

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

A single short sentence with no filler, front-loading the verb and resource. It is efficient but borders on under-specification rather than being genuinely tight, since nothing substantive follows the core statement.

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 hierarchical retrieval tool, the description never explains what the tree contains (folders, documents, nesting depth), so an agent cannot predict the shape or scale of the result. With no output schema available, the description should carry more of that burden than it does.

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

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

There is a single parameter with 100% schema description coverage ('Project ID or Key'), so the schema carries the semantics and baseline 3 applies. The description does not add any detail about accepted ID formats or whether a key works as well as an 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?

States a specific verb ('Gets') and a specific resource ('the document tree of a project'), which is meaningfully distinct from the sibling get_documents (list) and get_document (single item). It does not explicitly name those siblings or clarify what 'tree' means structurally, so it falls short of full sibling differentiation.

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

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

There is no guidance on when to use this versus get_documents, get_document, or get_wiki_pages, and no prerequisites or exclusions are stated. The agent must infer that this returns a hierarchical view while the other tools return flat/single results.

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

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

The annotations already declare this is a read-only, non-destructive, closed-world operation. The description adds only the project scoping and does not disclose pagination behavior, permission requirements, or what happens when neither projectId nor projectKey is supplied.

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. Every word contributes to stating the resource and its project scope.

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

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

For a simple read-only list tool with fully described parameters and safety annotations, the description is minimally adequate. However, because both parameters are optional, it does not clarify whether omitting both returns all repositories or is an error, which is relevant context for correct 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 100%, so both parameters are fully documented in the schema with examples. The description's phrase 'for a project' reinforces project scoping but does not explain the relationship or choice between projectId and projectKey beyond what the schema already provides.

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

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

The description states a specific verb and resource: it returns a list of Git repositories scoped to a project. This is clear enough for an agent, but it does not explicitly distinguish itself from the sibling get_git_repository tool, which likely returns a single repository.

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 get_git_repository or any other sibling. The phrase 'for a project' implies it lists repositories in a project, but there are no exclusions, prerequisites, or alternatives 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered; the description adds nothing beyond that—no note on permission requirements, errors when the repo id/name doesn't resolve, or what fields come back.

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

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

A single, front-loaded sentence with no filler. It is efficient, though its brevity is partly the cause of the missing guidance rather than deliberate compression.

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 four optional parameters, no output schema, and rich annotations, the description should at least say which identifier selects the repository and roughly what is returned. Instead it leaves both the identification semantics and the response shape entirely to inference.

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

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

Schema description coverage is 100%, so all four parameters (repoId, repoName, projectId, projectKey) are documented in the schema and the baseline is 3. Notably all four are optional, and the description does not clarify whether one identifier is required or which is preferred, adding 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?

States a specific verb+resource: 'Returns information about a specific Git repository.' The singular 'a specific' implicitly contrasts with the sibling get_git_repositories (plural listing), but it never names that sibling or states the distinction explicitly.

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 when-to-use guidance, no prerequisites, and no routing to get_git_repositories for listing versus this tool for a single repo. The agent must infer the distinction from the name alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds no behavioral context beyond restating that this is a read operation—it doesn't mention error cases, required identifiers, or return characteristics.

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, though it is arguably too terse.

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 simple read nature, annotations, and full schema coverage, the description is minimally adequate. However, it does not clarify that at least one of issueId or issueKey must be supplied (since neither is required by schema), and it omits any mention of what information is returned.

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

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

Schema description coverage is 100%, so both issueId and issueKey are fully documented in the schema. The description adds no additional meaning about parameter semantics, which is expected at this coverage level.

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?

It states a specific verb ('Returns') and resource ('information about a specific issue'), making the basic operation clear. However, it does not distinguish the tool from siblings like get_issues, get_related_issues, or get_issue_comments.

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, nor does it state prerequisites or identifier requirements. The only usage signal is implicit in the name and resource.

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 readOnlyHint/destructiveHint/openWorldHint already declaring a safe read, the description adds real behavioral context: the default auto behavior of rendering raster images as MCP image content, and the warning that base64 mode places the whole encoding in the caller's context. It omits the maxBytes cap and default, which is a meaningful behavioral detail.

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

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

Three tight sentences: purpose first, return modes second, prerequisite last. Nothing is padded and the most decision-relevant information leads.

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

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

With no output schema, the description correctly compensates by describing return shapes (image content, embedded resource, base64 JSON). It falls short on the optional issueId/issueKey parameters and the maxBytes default, which an agent needs to call the tool optimally.

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 100% and the schema already documents format, attachmentId provenance, and maxBytes limits, so the description largely mirrors structured data. It offers no explanation of why issueId/issueKey are accepted alongside attachmentId, leaving the multi-param authorization semantics 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?

States a specific verb and resource ('Downloads one attachment of an issue') and immediately clarifies the return shape, which lets an agent distinguish it from get_issue or the comment/wiki siblings.

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

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

Explicitly routes the agent: 'Call get_issue first to obtain the attachmentId', and distinguishes the two return modes. It does not state when not to use the tool or how issueId/issueKey interact with attachmentId, so it stops short of full when/when-not coverage.

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 already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds no behavioral context whatsoever – no default sort order, no default/max page size, no statement of what happens when neither issueId nor issueKey is given, and no pagination semantics for minId/maxId.

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

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

One efficient sentence with no filler, but its brevity is under-specification rather than disciplined economy – the operation's key constraint (an issue identifier is effectively required) is omitted 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?

For a 6-parameter tool with zero required parameters and no output schema, the description should clarify the identifier requirement and paging behavior. Without it an agent could call the tool with no arguments and get an ambiguous result.

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

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

Schema description coverage is 100%, so every parameter including the minId/maxId paging pair and the asc/desc enum is already documented in the schema. The description contributes nothing beyond that, which is the baseline expectation at full coverage.

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

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

States a specific verb and resource ('Returns list of comments for an issue'), which lets an agent distinguish it from the sibling mutation tools add_issue_comment/update_issue_comment and from get_pull_request_comments/get_document_comments by resource. It stops short of explicitly naming those alternatives, so no sibling differentiation credit.

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

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

No guidance on when to use this versus the other comment getters, no note that issueId or issueKey must be supplied (both are optional in the schema), and no mention of defaults for count/order. The agent is left to infer the calling contract entirely from the schema.

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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered elsewhere. The description adds nothing beyond that: no note on default page size, ordering defaults when sort/order are omitted, whether filters combine with AND, or how large result sets behave.

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?

Four words with no padding and nothing buried, so structurally clean and front-loaded. But the brevity comes from omission rather than economy - there is no substantive content to be concise about.

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

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

A 25-parameter, zero-required retrieval tool with pagination, sorting, date ranges, and polymorphic custom-field filters gets a five-word description and no output schema. Nothing tells the agent how to page, what the defaults are, or what shape the returned list takes - completely inadequate for the 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 description coverage is 100%, so all 25 parameters including the nested customFields oneOf variants are documented in the schema itself; baseline 3 applies. The description contributes zero additional meaning - notably it never explains whether the many ID-array filters are ORed within a field and ANDed across fields, which is the main ambiguity the schema leaves.

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?

"Returns list of issues" restates the tool name almost verbatim; the only added signal is the plural "list", which weakly implies bulk retrieval versus the sibling get_issue. It names no scope, no filter semantics, and does not distinguish itself from count_issues, get_issue, or get_related_issues.

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

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

There is no when-to-use guidance at all: no mention that this is the filtered/bulk retrieval path, no pointer to count_issues for totals, no note that get_issue should be used for a single issue by ID. The agent must infer routing from sibling names alone.

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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that — no note on whether the list is paginated, cached, or whether it reflects archived issue types.

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

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

A single front-loaded sentence with no waste. It is efficient but borders on under-specified for a lookup whose identifier semantics are ambiguous.

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

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

For a simple read-only lookup with a fully documented schema and clear annotations, this is close to adequate. The remaining gap is the projectId-vs-projectKey choice and whether one is required, which neither schema nor description resolves.

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 100%, so both projectId and projectKey are documented with examples, and the baseline is 3. However, the description doesn't clarify the important fact that both parameters are optional and presumably either identifies the project — an agent could call with neither and the description gives no warning.

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

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

States a specific verb+resource ('Returns list of issue types') scoped to a project, which is enough to distinguish it from nearby lookup siblings like get_categories, get_priorities, and get_resolutions. It stops short of explicitly naming those siblings or how they differ.

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 when-to-use, when-not, or alternative is given. The phrase 'for a project' only weakly implies the tool is scoped to a single project; nothing tells the agent when to prefer issue types over custom fields or priorities.

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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no note about what identity context it requires, whether it may fail when unauthenticated, or what fields come back — so it earns no credit over the annotations.

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

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

A single short sentence with no waste and the key qualifier ('authenticated user') up front. Efficiency is fine, but the extreme brevity leaves substance gaps rather than trimming 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 no-param read tool with annotations and no output schema, the definition is minimally viable. It still omits the most useful thing an agent would want — roughly what user fields are returned (id, name, email) and whether this is the canonical way to resolve 'me' before calling user-scoped 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the empty schema is self-explanatory. Baseline for a no-parameter tool applies.

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

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

States a specific verb ('Returns') and resource ('information about the authenticated user'), which implicitly distinguishes it from the sibling get_users that targets arbitrary users. It does not explicitly name that sibling or say what 'information' is included, so it falls short of full sibling differentiation.

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

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

There is no statement of when to use this tool versus get_users or get_user_recent_updates, and no prerequisites or exclusions. The intended use (fetch the caller's own identity) is only weakly implied by the phrase 'authenticated user'.

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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured fields. The description adds nothing beyond that — no pagination behavior, no default ordering, no note on whether results are capped by count.

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

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

A single short sentence with no filler, so it is not bloated. However, its brevity comes at the cost of under-specification rather than efficiency — there is no front-loaded scope or key constraint.

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 four optional ID/order parameters and no output schema, the description should clarify what a notification record contains, how ordering interacts with count, and whether ID ranges are inclusive. None of this is present, leaving the agent to guess at retrieval semantics.

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

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

Schema description coverage is 100%, so all four parameters (count, maxId, minId, order) are already documented in the schema. The description adds no extra meaning such as whether minId/maxId are inclusive or what the default sort order is; baseline 3 applies.

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

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

"Returns list of notifications" essentially restates the tool name (get_notifications) with the addition of the word "list". It does not distinguish this from count_notifications or mark_notification_as_read, nor does it describe scope, filtering, or ordering behavior.

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

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

No guidance on when to use this versus count_notifications or mark_notification_as_read, and no mention of prerequisites such as authentication or unread state. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing behavioral on top: no mention of ordering, global vs. project scoping, caching, or typical list size. With annotations carrying the burden, this is a bare-minimum 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?

One short sentence with zero padding, which is efficient. However, it is under-specified rather than concise-in-service-of-clarity — the brevity comes from omitting useful information, not from tight editing.

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

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

With no parameters, no output schema, and no annotations describing return shape, the description is the only place to say what a "priority" actually is in this system. It does not, leaving the agent unable to predict what the returned list contains or how to use it.

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

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

The tool takes zero parameters and the schema is an empty object, so there is nothing for the description to explain. Baseline 4 applies; no parameter-level value is withheld.

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?

"Returns list of priorities" gives a verb (returns) and a resource (priorities), so the basic operation is legible. But "priorities" is never disambiguated — it could be an issue-priority master list, a ranking of issues, or personal priorities — and the description does nothing to distinguish it from look-alike siblings such as get_issue_types, get_resolutions, get_categories, and get_custom_fields.

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

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

There is no when-to-use guidance, no exclusion, and no mention of the alternative lookup tools in the sibling set. The agent must infer from the name alone that this is the master-data enumeration used when setting an issue's priority.

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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond that — no note on behavior when the project is not found, no indication of what subset of project data is returned, and no mention that projectId/projectKey are alternative lookup keys.

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

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

A single short sentence with no wasted words, and the verb+resource is front-loaded. Its brevity borders on under-specification, but nothing is padded or redundant.

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

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

There is no output schema, so the description is the only place to convey what 'information' means (fields returned, shape, behavior on missing project), and it does not. For a lookup tool that returns an entity, this leaves a meaningful 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 100% and both parameters carry examples in the schema, so the baseline applies. The description adds no clarification of the important ambiguity that zero parameters are required yet one of projectId or projectKey must presumably be supplied.

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

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

States a specific verb ('Returns') and resource ('information about a specific project'), so the agent knows it is a single-record lookup. It does not explicitly distinguish itself from siblings like get_project_list or update_project, leaving the single-vs-list distinction to inference from the word 'specific'.

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

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

No guidance on when to use this versus get_project_list, get_project_users, or update_project. The agent must infer from the name alone that this is the single-project read path.

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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, covering the safety profile. The description adds nothing beyond that — no mention that the result set depends on admin status or archived state, which is the key behavioral nuance of this 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 single sentence is front-loaded and free of waste, but it is under-specified rather than concise — it stops well short of what an agent needs. Brevity here reflects thin content, not efficiency.

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

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

For a list tool with no output schema, the description says nothing about what a returned project contains, ordering, pagination, or how the default call behaves (joined projects only). Against 60+ siblings including get_project, this leaves the agent guessing.

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

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

Schema description coverage is 100%, and the schema itself explains the 'all' and 'archived' semantics thoroughly, including defaults. The description contributes no additional parameter meaning, so the baseline 3 applies.

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

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

The description states a specific verb ('Returns') and resource ('list of projects'), so the basic purpose is recoverable. However, with siblings like get_project (singular) and get_project_users present, it offers no differentiation — an agent cannot tell from the text alone how this list differs from fetching a single 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?

There is no guidance on when to call this versus get_project or get_project_users, and no mention of prerequisites such as admin rights implied by the 'all' parameter. The agent gets no selection criteria at all.

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 already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds nothing beyond that: no pagination behavior, no result size expectations, and no note that the lookup is scoped to a single project's membership.

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

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

A single front-loaded sentence with no filler. It is terse to the point of under-specification, but nothing is wasted.

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

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

No output schema exists, so the description must carry return-shape information and does not — no word on what a 'user' object contains or whether results are paginated. Combined with the unresolved projectId-vs-projectKey question from the optional parameters, an agent lacks enough context to call this confidently.

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

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

Schema description coverage is 100%, so both projectId and projectKey are documented in the schema, giving baseline 3. However, the description misses a meaningful semantic point: the schema marks zero required parameters, leaving an agent unsure whether one identifier, either, or both must be supplied — this is exactly the kind of clarification a description should add and it does not.

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

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

States a specific verb and resource with scope ('Returns list of users in a specific project'). This implicitly separates it from the broader get_users sibling, though the distinction is never made explicit.

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

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

No guidance on when to use this versus get_users (list all users) or get_myself. The agent must infer that this tool is the project-scoped variant from the name and resource alone.

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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that – no mention of what fields come back, what happens when the PR number or repo identifiers don't resolve, or how the repoId/repoName and projectId/projectKey pairs interact. With no output schema, some of this burden falls on the description.

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

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

A single front-loaded sentence with zero filler. Brevity is appropriate, though it tips into under-specification given the tool's identifier complexity.

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 five parameters forming alternative identifier pairs, one required field, and no output schema, the description should clarify which identifiers suffice and roughly what is returned. It leaves both questions entirely to the schema, which only labels the fields.

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

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

Schema description coverage is 100%, and all five parameters carry descriptions, so the baseline of 3 applies. The description adds no meaning beyond the schema, notably silent on why both repoId and repoName (and projectId and projectKey) exist as alternative identifiers.

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

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

States a specific verb ('Returns') and resource ('information about a specific pull request'), and the word 'specific' signals single-resource retrieval as opposed to the sibling get_pull_requests list. It does not explicitly name the sibling, so differentiation is implied rather than stated.

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

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

No guidance on when to use this versus get_pull_requests (list) or get_pull_request_comments. The agent must infer from the name alone that this is for fetching one PR by number.

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 already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that — no mention of pagination behavior, default ordering, whether all comments are returned, or what the response contains.

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

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

A single front-loaded sentence with no wasted words. It is appropriately terse, though the brevity comes at the cost of the behavioral and usage detail captured above.

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 nine-parameter read tool with pagination-style parameters and no output schema, the description says far too little. It never explains how count/minId/maxId affect the result set or whether the list is complete or paged.

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

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

Schema description coverage is 100%, so all nine parameters (count, minId/maxId, order, repoId, projectId, etc.) are already documented in the schema. The description adds no meaning beyond that, which is acceptable given the baseline for high coverage.

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

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

States a specific verb (returns list) and resource (comments for a pull request), so an agent knows exactly what it fetches. It does not distinguish itself from get_issue_comments or explain why get_pull_request_comments is preferable, leaving that inference to the agent.

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

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

No guidance on when to use this versus get_pull_request, add_pull_request_comment, or get_issue_comments. The description states what happens but not the context or prerequisites for calling 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the repository scoping and says nothing about default ordering, default page size, how multiple filters combine, or whether an unfiltered call returns all PRs — meaningful gaps even under the lower annotated bar.

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

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

A single front-loaded sentence with zero filler, so it is efficient. It leans toward under-specification rather than verbosity, but nothing is wasted.

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

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

With ten optional parameters and no output schema, the description should explain the filtering model and default pagination behavior; it does neither. An agent could call it, but not confidently predict whether it gets all PRs, a default page, or how the filter arrays behave.

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

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

Schema description coverage is 100%, so all ten parameters are documented in the schema itself and the baseline is 3. The description adds no additional meaning about filter semantics (e.g., whether issueId/statusId/assigneeId are OR'd or AND'd, or what count/offset default to), so it neither helps nor harms 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 names a specific verb and resource ("Returns list of pull requests") and scopes it to a repository, so an agent knows exactly what it fetches. It does not, however, distinguish it from close siblings like get_pull_requests_count or get_pull_request, which an agent must infer from the names alone.

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

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

There is no guidance on when to use this versus get_pull_request (single) or get_pull_requests_count, nor any statement of prerequisites or exclusions. The agent is left to infer that this is the bulk/filtered listing variant.

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 already declare the operation is read-only, non-destructive, and closed-world, so the safety profile is covered. The description adds that the result is an aggregate count rather than a list, but it does not explain filter behavior, default counting scope when no parameters are supplied, or permissions.

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 count tool, though its brevity contributes to gaps addressed under 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?

The tool has eight optional filter parameters and no output schema, yet the description only says the count is 'for a repository.' It omits that the count can be filtered by project, issue, status, assignee, and creator, and does not explain what happens when no repository identifier or filters are supplied.

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

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

Schema description coverage is 100%, so all eight optional parameters are already documented in the schema. The description mentions only 'repository' and does not add meaning about how issueId, statusId, assigneeId, createdUserId, or project filters affect the count, leaving the baseline score 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 states a specific verb ('Returns count') and resource ('pull requests') scoped to a repository, which distinguishes it from the sibling get_pull_requests that retrieves PRs rather than counting them. It does not, however, mention the broader project/issue/status/assignee filtering implied by the schema.

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

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

There is no explicit guidance on when to use this tool instead of get_pull_requests or get_pull_request. The 'count' wording implies aggregate use, but the description provides no conditions, exclusions, or named 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only the fact that the result is a list rather than a single issue — marginal, but not contradictory, value on top of the annotations.

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

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

A single front-loaded sentence with no filler or repetition. It is efficiently written, though efficiency here reflects under-specification rather than disciplined editing.

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

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

With no output schema and zero required parameters, the description should clarify what a "related issue" is, whether the result is paginated, and whether issueId or issueKey (or both) should be supplied. None of that is present, so an agent must guess at the return shape for a list-producing 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 100% and both parameters carry their own examples ('PROJ-123', 12345), so the description does not need to explain them. It also offers no guidance on the fact that both are optional and how they interact (either/or vs. both), leaving that to the schema 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 states a verb and resource ("Returns list of issues related to a specific issue"), so the basic purpose is recoverable. However, "related" is never defined and nothing distinguishes it from siblings like get_issue, get_issue_comments, or add_related_issue — an agent cannot tell which tool supplies the "related" graph data on its own.

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

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

There is no when-to-use guidance, no exclusion of alternatives, and no mention of the obvious companions add_related_issue/remove_related_issue that manage the same relation. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds no further behavioral context such as ordering, whether the list is exhaustive, or whether default/uncategorized resolutions are included.

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

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

A single five-word sentence with the resource front-loaded and no filler. It is efficient, though it borders on under-specification rather than optimal density.

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

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

For a zero-parameter reference-list tool with annotations covering safety, the definition is minimally adequate. With no output schema, the description could state what each entry contains (id, name) and whether the list is filtered by project, which it omits.

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 takes zero parameters, so parameter semantics are not a concern and the baseline of 4 applies. Nothing in the description is needed to explain inputs.

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

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

States a specific verb and resource: 'Returns list of issue resolutions'. An agent can tell it returns reference data rather than resolving an issue. It does not differentiate itself from analogous sibling lookup tools such as get_priorities or get_issue_types.

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 call it, e.g. to discover valid resolution values before calling update_issue, and no mention of prerequisites or alternatives. The agent must infer the use case from the name alone.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond them, such as what fields the returned space record contains or whether any caching/auth scope applies; it essentially restates the tool name.

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

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

A single, front-loaded sentence with no wasted words. It is efficient, though also thin, so it earns a solid rather than top score.

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

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

With no output schema and no annotations covering the return payload, the description should indicate what information about the space is returned (name, domain, settings, etc.). It leaves the agent unable to predict the response shape for even a simple read.

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 takes zero parameters, so there is no parameter semantics to document; the schema is empty and complete. Baseline for a zero-param tool is 4.

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

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

States a specific verb and resource: returns information about the Backlog space. An agent can tell it is a read of the space-level resource, though it does not distinguish itself from near-neighbors like get_myself, get_users, or get_space_activities.

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 call this versus the numerous sibling getters, and no mention of prerequisites such as authentication.

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 already declare readOnly=true, destructive=false, openWorld=false, so the safety profile is fully covered and the description adds nothing. It does not disclose pagination behavior, default ordering, default count, or what happens when no ID bounds are supplied — meaningful gaps for a list endpoint with five optional filters.

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 single sentence contains no filler, so nothing is wasteful, but it is terse to the point of under-specification rather than efficient packaging of information. There is no front-loaded scope, default behavior, or return-shape hint.

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

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

A five-parameter, enum-bearing list endpoint with no output schema needs the description to explain paging semantics and the meaning of ID-range filtering. The description covers none of this, leaving the agent to reverse-engineer behavior from parameter names.

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

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

Schema description coverage is 100%, with each of the five parameters documented (count, minId/maxId, order, activityTypeId). The description adds no syntax or semantic context beyond that — e.g., what an activityTypeId of -1 means — so the baseline 3 applies.

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

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

The description names a specific verb and resource ("Returns list of space activities"), so an agent can infer this is a read/list operation. However, it does not clarify what a "space activity" is (feed entries? audit log? status updates?) nor distinguish it from siblings like get_user_recent_updates or get_notifications, which plausibly return overlapping content.

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 call this versus alternatives, no prerequisite (e.g., a space context), and no mention of whether it is a feed-style listing with paging. The agent must guess based on the name alone.

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 already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds no behavioral context beyond restating the resource—it does not define what 'recent' means, how pagination via maxId/minId behaves, or what activity fields are returned.

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 arguably too sparse for a six-parameter tool, but it is not verbose or poorly structured.

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?

Annotations cover safety and the schema fully documents parameters, but the description does not clarify behavioral details like the 'recent' window, default ordering, or how ID-based pagination should be used. Adequate for invocation, but with clear gaps for a multi-filter activity retrieval 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 100%, so all six parameters are documented in the schema, including defaults, ranges, and enum values. The description adds no parameter-level meaning beyond the schema, making the baseline 3 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?

States a clear verb ('Returns') and resource ('recent updates (activities) for a specific user'), so an agent knows exactly what the tool fetches. It does not distinguish itself from siblings such as get_space_activities, which also returns activity-like data, leaving the scope boundary implicit.

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 no guidance on when to use this tool versus alternatives like get_space_activities or get_watching_list_items. There are no exclusions, prerequisites, or usage conditions 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds nothing beyond that: no return shape, no ordering, no note on whether the list is complete or truncated, and no mention of pagination behavior (which matters here because there are no parameters to paginate with).

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

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

A single short sentence with no filler, front-loading the verb and resource. The only minor waste is 'in the Backlog space', which restates where every tool in this server already operates.

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

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

For a zero-parameter read tool with no output schema, the description is minimally adequate. However, with no parameters to filter or limit results, an agent would benefit from knowing whether the list is paginated, truncated, or ordered — none of which is stated, and with no output schema it cannot be learned from structured fields.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The schema is empty and 100% covered by definition; the description correctly says nothing about inputs.

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

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

States a specific verb ('Returns') and resource ('list of users') with the scope 'in the Backlog space', so the agent knows exactly what comes back. It only implicitly distinguishes itself from space-scoped siblings like get_myself, get_project_users, or get_space; a reader has to infer that 'the Backlog space' means the whole space rather than a 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?

Usage is implied: fetch users who live in this Backlog space. There is no explicit 'when to use this vs get_myself / get_project_users' guidance, and no statement about whether project-scoped user lists are a different tool. An agent must infer the boundary from the description and sibling 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?

The annotations already establish that this is a safe, read-only, non-destructive, closed-world operation. The description adds no behavioral context beyond that—it does not mention date-range filtering, result semantics, or any other operational detail.

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?

It is a single front-loaded sentence with no filler. Every word contributes to stating the core purpose.

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 count tool with a fully documented schema and clear safety annotations, the description is minimally adequate. However, it omits what the count represents exactly (total vs. filtered) and provides no indication of return behavior, which would be helpful since there is no output 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?

Schema description coverage is 100%, so the schema already fully documents `userId`, `since`, and `until`. The description adds no parameter meaning beyond the schema, which meets the baseline 3 for full 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 gives a clear verb (returns) and resource (count of stars received by a user), which is unambiguous and distinct from the sibling list. It does not explicitly differentiate from other count tools, but none of the siblings cover user-star counts, so disambiguation is not critical.

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, nor any exclusions or prerequisites. Usage is only implied by the tool name and the idea of retrieving a count.

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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds only the vague phrase 'in the Backlog space' – no pagination behavior, no result ordering, no disclosure of what happens with zero filters, which is the key behavioral question for a list endpoint with all-optional params.

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

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

A single front-loaded sentence with no wasted words, so it is not verbose. But the terseness comes at the cost of under-specification rather than efficient communication.

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 list tool with two optional filters, no output schema, and no required parameters, the agent needs to know default scoping and return shape. Neither is present; the description is little more than a restatement of the name.

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

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

Schema description coverage is 100% and both parameters carry examples, so the schema does the heavy lifting. The description mentions neither parameter and adds no filtering semantics (e.g. whether projectId and projectKey are alternatives or combinable), which is the baseline-3 outcome.

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