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

No annotations are provided, so the description carries the burden of behavioral disclosure. It only restates the action ('Add') without covering side effects, permissions, idempotency, or what happens on success. Some useful detail exists in the schema for the comment parameter, but not in the tool description itself.

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

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

The description is a single concise sentence with no filler. It is front-loaded and easy to parse, though it is minimal and adds little beyond the tool's name.

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

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

For a simple three-parameter tool with full schema coverage and an output schema, the description is minimally sufficient. However, with no annotations and no usage guidance, it leaves the agent without behavioral context such as permissions or side effects, so it is only adequately complete rather than fully.

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 parameters are already well documented. The description adds no additional parameter meaning, but the structured schema carries the load, making 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 uses a specific verb and resource: 'Add a comment to a work item.' It clearly identifies the operation and target, distinguishing it from comment-related siblings like list_comments, update_comment, and delete_comment, though it does not explicitly name those alternatives.

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

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

The description gives no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or context for commenting on a work item. It relies entirely on the tool name and schema.

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

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

With no annotations provided, the description carries the behavioral burden. It discloses that the endpoint is permission-gated on some workspaces/editions and that it may return 403, which is valuable beyond the schema. It doesn't describe return format or side effects, but 'search' strongly implies a read-only list operation.

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

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

Three short sentences, front-loaded with the core purpose, followed by a relevant capability note and a fallback. Every sentence earns its place and there is no filler.

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

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

For a 5-optional-parameter search tool with no output schema, the description is quite complete: it explains the advanced filtering nature, the permission caveat, and fallback alternatives. It could mention what kind of result shape to expect, but the sibling context and name make the return type reasonably inferable.

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 some semantic meaning by noting that the filters object is supported in addition to a text query, but it does not elaborate on filter structure or parameter relationships beyond what the schema already states.

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 ('Filtered work item search') and immediately keys in on the differentiator: it uses Plane's advanced-search endpoint with a structured filters object plus a text query. It clearly distinguishes itself from simpler siblings by name and 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?

The description gives explicit when-to-use context: structured filters are supported in addition to a text query. It also provides a concrete fallback instruction — if the endpoint returns 403, use search_work_items or list_work_items — which is direct, actionable guidance.

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

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

With no annotations, the description carries the behavioral burden. It discloses that archiving is reversible and points to restore_page, which is valuable, but it does not explain visibility effects, permission requirements, or what happens to the page after archiving.

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

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

Two short sentences, front-loaded with the primary action, with no filler. The reversibility note earns its place because it is a non-obvious behavioral fact.

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

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

The tool is simple, the schema is complete, and an output schema exists, so return values need no explanation. However, the description lacks any mention of when to choose archiving over deletion and what archiving changes for users, leaving a meaningful contextual 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%, so the schema already documents both parameters completely. The description adds no parameter-level meaning, keeping 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, 'Archive a page,' and immediately adds the key distinguishing trait: archiving is reversible via restore_page. This helps an agent separate it from permanent deletion tools like delete_page.

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 archive_page versus delete_page or other page-mutation siblings. The reversibility note implies when one might prefer archiving, but it is never stated as a usage rule or alternative selection criterion.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a mutation ('Create') but doesn't mention permission requirements, error behavior (e.g., duplicate label names), reversibility, or what the response contains. The output schema exists but the description adds no 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?

The description is a single, efficient sentence with no filler. It front-loads the core action and resource. However, its brevity borders on under-specification rather than deliberate conciseness, but it does not waste words.

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

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

For a mutation tool with no annotations, the description is incomplete. It does not explain what happens if the project_id is invalid, whether labels can be duplicated, or how to interpret the output schema. The output schema exists, but the description fails to set expectations about side effects or failure modes.

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 are already documented in the input schema. The description adds no extra meaning about parameter semantics, only the implicit intent of creating a label. Baseline 3 is appropriate since the schema carries the semantic load.

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 ('Create') and a specific resource ('a label in a project'). It distinguishes the tool from listing or updating labels, though it doesn't contrast with sibling creation tools like create_project or create_work_item. The resource is unambiguous and the scope is clear.

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

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

No guidance is given on when to use this tool versus alternatives, nor any prerequisites such as the project needing to exist first. The description merely states the action without context on typical use cases or exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that a page is created and gives no information about permissions, side effects, locking behavior, access defaults, or what happens after creation. This is a meaningful gap for a mutation tool.

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

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

The description is a single, focused sentence with no filler. It front-loads the core action and immediately conveys the key scope distinction.

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?

Although the tool has eight parameters, the schema describes each one completely, and an output schema exists. The description plus schema is largely sufficient for correct invocation; only richer behavioral caveats are missing.

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

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

Schema description coverage is 100%, so the schema fully documents all eight parameters. The description adds only a high-level scope distinction and no additional parameter-level meaning, so the schema-heavy baseline of 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 starts with a specific verb and resource ('Create a page') and immediately clarifies the two valid scopes: workspace wiki page or page inside a project. This clearly distinguishes it from sibling tools like create_project and create_work_item.

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 communicates the general context but does not explicitly say when to choose this tool over alternatives, nor does it provide exclusions or prerequisites. The workspace-vs-project distinction is present but only implied rather than framed as a decision rule.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. Beyond the verb 'create', it reveals nothing about side effects, required permissions, uniqueness constraints, or what happens on success/failure.

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

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

The description is extremely short, but brevity is achieved by omitting substance rather than by concise writing. It repeats the title and provides no information that earns its place.

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

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

Parameter details are covered by the schema and an output schema exists, so the agent can construct the call mechanically. However, with no annotations and no behavioral or usage context, the description is incomplete for distinguishing creation from updates or for understanding constraints like identifier collisions and member UUIDs.

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 input schema already documents all six parameters and their roles. The description adds no parameter-level meaning, but because the schema is complete, the baseline of 3 applies.

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

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

The description is a verbatim restatement of the tool name/title ('Create Project' → 'Create a project.'), adding no scope, qualifiers, or boundary information. It names the action and object, but is effectively a tautology and does not distinguish from sibling tools like update_project or create_work_item.

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 such as update_project or create_work_item. No prerequisites, required permissions, or conditions are mentioned, leaving the agent to infer usage from the name alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'create' without mentioning side effects (e.g., creating a persistent record), any permission requirements, or the fact that it's a write operation. The schema documents parameters, but the description does not explain what happens when the tool is called, leaving behavioral expectations vague.

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

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

The description is a single sentence with zero filler, making it very concise and readable. The key information (action and resource) is front-loaded. However, it is so minimal that it borders on tautological with the title, but it still earns its place by adding 'in a project' and being clearly 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?

With 12 parameters and no annotations, the description does not supplement the schema with necessary context. The schema already covers parameter formats and lookup instructions, and the output schema presumably covers return values, but the description omits any usage context, behavioral notes, or mention of required permissions. For a mutation tool, the description is not complete enough to guide an agent without additional 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 coverage is 100%, with each parameter already having a description (e.g., 'use list_states to find it', 'ISO date'). The tool description itself adds no additional parameter semantics, so the baseline of 3 is appropriate. The schema does the heavy lifting, and the description neither helps nor harms beyond that.

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 ('create') and resource ('work item', 'project'), clearly indicating the action. It doesn't explicitly differentiate from siblings like update_work_item or list_work_items, but the verb makes the purpose unambiguous. The title and description are consistent, and the wording is specific enough for an agent to understand the core action.

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

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

The description provides no guidance on when to use this tool versus alternatives. It neither mentions related tools nor states prerequisites like 'when you need to add a new item to a project' or 'when a work item does not already exist'. With no context about selecting this over update_work_item or list_work_items, the agent is left to infer usage from the name alone.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly states that the deletion is permanent and irreversible ('This cannot be undone'), which is the critical behavioral trait for a destructive operation. It does not mention permissions or side effects, but the core risk is well communicated.

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

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

The description is two short sentences with no wasted words. The key fact (permanent deletion) is front-loaded, and the irreversibility warning is placed immediately after.

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 destructive tool with a complete schema and an output schema, the description covers the essential behavioral context. It could mention the need for the comment to come from list_comments, but that is already in the schema, so the overall package is sufficient.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description itself adds no parameter-level meaning beyond what the schema provides, which warrants the baseline score of 3.

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

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

The description states a specific action ('Permanently delete') and a specific resource ('work item comment'), making the tool's purpose unmistakable. It also distinguishes itself from sibling tools like add_comment and update_comment by emphasizing permanence.

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

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

No guidance is given about when to use this tool versus alternatives such as update_comment or delete_work_item. The description does not mention any conditions, prerequisites, or exclusions, leaving the agent to infer usage context.

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

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

With no annotations, the description carries the full burden. It discloses permanence ('Permanently delete', 'cannot be undone') and the rejection behavior for active pages. It does not mention permission requirements or cascading effects on related resources, but the core mutating and irreversible nature is well covered. Slight gap on side effects prevents a 5.

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

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

Three sentences, zero filler. The purpose is stated first, then the prerequisite, then the constraint. Every sentence earns its place, and the most critical information (permanence and prerequisite) is front-loaded.

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 presence of an output schema means return values are already covered. The description explains the action, the required precondition, the system's rejection behavior, and irreversibility. It doesn't specify error handling for invalid IDs or whether deletion cascades to comments, but for a delete tool with a well-defined schema, this is nearly complete. Minor omissions prevent a 5.

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% — both page_id and project_id have descriptive comments in the schema (UUID for page, project UUID for project pages vs. workspace wiki). The tool description adds no parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description opens with 'Permanently delete a page', a specific verb + resource, and the qualifier 'permanently' clearly distinguishes it from the sibling archive_page. The resource and action are unambiguous, and the mention of rejection on active pages reinforces the delete semantics.

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 states the precondition: 'The page must be archived first' and instructs the agent to 'call archive_page before this'. It also explains why (Plane rejects active pages), giving clear when-to-use guidance and implicitly differentiating from restore_page and archive_page.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It clearly states the operation is permanent and cannot be undone. It could go further by mentioning cascading effects or permission needs, but the key destructive trait is well covered.

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

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

Two short sentences: the first front-loads the most important behavioral fact (permanent, irreversible), and the second provides the key alternative. No wasted words.

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

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

For a low-complexity tool with only two required parameters and an output schema present, the description includes all necessary selection and invocation context: destructive semantics, irreversibility, and the alternative for closing items.

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?

Input schema coverage is 100% and already describes both parameters as UUIDs. The description adds no parameter-specific meaning, which is acceptable because the schema handles it. 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?

States a specific verb ('delete') and resource ('work item'), and clearly indicates the destructive, permanent nature. It also implies the difference from update_work_item by mentioning the alternative, making it easy to distinguish from 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 tells when not to use this tool: when the intent is to close a work item, and names the alternative tool (update_work_item) and the preferred state ('Cancelled'). This is direct, actionable routing guidance.

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

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

With no annotations provided, the description carries the full burden. It clearly signals a read-only retrieval operation via 'Return', and identifies the scope (the API key's owner). For a zero-parameter, non-destructive tool, this is sufficient behavioral disclosure—nothing is hidden or surprising.

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

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

The description is a single, focused sentence. It front-loads the action and resource, contains zero filler words, and conveys all essential information without 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 zero-parameter tool with an output schema, the description is fully sufficient. It states what is returned and the authentication context (API key owner). There are no prerequisites, side effects, or edge cases an agent needs to be warned about.

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

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

The tool has zero parameters, so the description does not need to explain any. The schema covers all (zero) parameters, and with 100% schema description coverage, the baseline for no parameters is 4. The description adds no parameter information but none is needed.

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

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

The description states a specific action ('Return the profile') and a clear resource ('the user the Plane API key belongs to'). This uniquely distinguishes it from all sibling tools, which target other resources like work items, projects, or 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 context is clear: use this tool when you need information about the currently authenticated user. While no exclusions or alternatives are explicitly mentioned, the tool's self-contained nature and unique purpose make the appropriate usage obvious.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. The verb 'Fetch' implies a read-only operation, but the description does not explicitly state that it has no side effects or require any permissions. For a simple fetch, this is adequate but not rich; it does not mention return format or error behavior, though the output schema covers some of this.

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

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

The description is a single, focused sentence that front-loads the primary action and resource. It contains no filler or redundancy, making it efficient for an agent to parse.

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

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

Given the tool's simplicity, the existence of an output schema, and the complete parameter documentation, the description covers the essential context: what it does, what it takes, and the two page types. It does not explicitly mention error handling or pagination, but these are not critical for a single-fetch operation. The description is sufficient 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 well documented in the schema. The description's note about workspace vs project page adds context that mirrors the schema's project_id description, but does not introduce new semantics beyond what the schema already 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 specific verb ('Fetch') and resource ('page by UUID'), and clarifies the two possible page types (workspace wiki page or project page). This clearly distinguishes it from siblings like list_pages, update_page, and delete_page, which have different purposes.

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

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

The description provides clear context on when to use the tool: when you have a page UUID and need to retrieve a single page. It implicitly distinguishes from listing tools and project/work item fetchers, though it does not explicitly name alternatives or exclusions. The differentiation between workspace and project pages gives usage context.

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

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

No annotations are provided, so the description carries the full burden. It simply says 'Fetch a single project by its UUID' without disclosing error behavior (e.g., 404 for missing project), permission requirements, or any side effects. The verb implies read-only, but essential behavioral context is absent.

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

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

A single sentence with no filler; the core operation and identifier are stated in the most direct way possible. It is perfectly front-loaded and appropriately sized.

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

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

The tool is simple (single parameter, output schema provided), so the missing context is less severe than for complex tools. However, the description still lacks explicit usage guidance and behavioral disclaimers, making it only minimally complete for an agent deciding between this and sibling tools.

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

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

Schema description coverage is 100%: `project_id` already explains it is a Project UUID from `list_projects`. The tool description's phrase 'by its UUID' adds no new meaning, so the schema does the heavy lifting and the description provides no additional semantic value.

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 ('Fetch'), a specific resource ('a single project'), and the key parameter ('by its UUID'). It distinguishes from siblings like list_projects by the 'single' qualifier and from other get_* tools by naming 'project' as the resource.

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 alternative guidance. The parameter description hints that the UUID comes from `list_projects`, implying a workflow, but the tool description itself does not state when to choose `get_project` over `list_projects` or other retrieval tools. At best, usage is implied by the noun 'single project.'

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

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

With no annotations, the description must carry the behavioral burden, and 'Fetch' clearly signals a read-only operation with no mutation. However, it does not disclose error behavior, authentication requirements, or not-found outcomes, which would be useful for a tool with no annotation support.

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

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

A single, front-loaded sentence states the action and the two identifying values with no filler or redundant clauses. Every word contributes to the core instruction.

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

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

The tool is simple: two required parameters, no nested objects, and an output schema exists. The description plus schema fully cover the main calling scenario and even route the human-identifier case to a sibling tool, leaving little ambiguity for an agent.

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

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

Schema description coverage is 100%, so the parameters are already fully documented in the input schema. The description repeats the 'UUID' identifiers without adding semantic detail beyond what the schema already provides, meeting the baseline but not exceeding it.

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 ('Fetch') and resource ('work item') and identifies the two required UUIDs, so an agent can understand the core operation. It does not explicitly differentiate from the sibling `get_work_item_by_identifier`, though the parameter description supplies that distinction.

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

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

The description implies use when both project and work item UUIDs are available. The `work_item_id` parameter documentation adds an explicit when-not rule by directing agents to `get_work_item_by_identifier` when only a human-readable identifier is present.

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

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

With no annotations provided, the description carries the burden of explaining behavior. 'Fetch' clearly indicates a read-only operation, but the description does not disclose what happens for malformed identifiers or missing work items. It adds no behavioral context beyond the operation itself.

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

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

The description is one concise, front-loaded sentence that states the action, the resource, and a concrete example. Every element earns its place with no filler.

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

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

For a simple one-parameter getter with a rich schema and an output schema, the description is nearly sufficient. It could be more complete by naming get_work_item as the sibling for internal-ID lookups, but an agent can still invoke this tool correctly.

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

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

The input schema already documents the parameter format thoroughly with examples and an explicit note about the project identifier. The description reinforces the 'human identifier' concept but does not add meaning beyond what the schema already covers.

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

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

The description uses a specific verb and resource ('Fetch a work item') and adds the key qualifier 'by its human identifier', which makes the purpose immediately understandable. However, it does not explicitly differentiate this tool from the sibling get_work_item, so the distinction remains only implied.

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

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

The phrase 'by its human identifier' implies the intended use case, and the example PROJ-123 gives context. But there is no explicit statement of when to choose this tool over alternatives like get_work_item, search_work_items, or list_work_items.

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

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

With no annotations, the description carries the full disclosure burden. It only states the operation and does not mention that the call is read-only, how pagination behaves, whether results are ordered, or any permission/rate-limit considerations. 'List' implies non-mutating behavior, but explicit disclosure is absent.

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

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

A single, direct sentence with no wasted words. The verb, object, and scope are immediately clear.

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

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

The description is minimally viable for a simple list operation with a full output schema and documented parameters. It covers the what but not behavioral or usage nuances; an agent can invoke it correctly but without richer context about ordering, pagination behavior, or read-only guarantees.

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?

All three parameters are fully described in the schema (100% coverage), so the description adds no new semantic meaning beyond referencing the resource. Baseline 3 applies because the schema does the heavy lifting.

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

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

States a specific verb ('List'), resource ('comments'), and scope ('on a work item'). It clearly distinguishes from sibling mutation tools like add_comment, update_comment, and delete_comment, so an agent can immediately understand what this tool does.

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

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

The description gives clear context: this is the tool for retrieving comments on a work item. It does not explicitly name alternatives or exclusions, but no alternative listing tool exists among siblings, so the intended usage is unambiguous.

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

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

With no annotations, the description carries the full burden, but 'List' clearly signals a safe read operation. It does not disclose pagination behavior or filtering semantics beyond what the input schema already states, so it adds only modest 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?

The description is one short, well-scoped sentence that front-loads the core action and adds the clarifying parenthetical 'sprints'. No words are wasted.

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

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

For a simple list operation with full schema descriptions and an output schema, the description is nearly complete. It lacks only usage guidance and richer behavioral notes, but those are minor given the schema's clarity.

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 has a meaningful description. The tool description adds minimal parameter-level insight, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource ('List a project's cycles') and clarifies the domain term by glossing cycles as sprints. It is immediately clear what the tool does, and the resource is distinct from the sibling tools.

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

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

The description provides no guidance on when to use this tool versus alternatives such as list_states or list_modules. It only states the basic action, leaving the agent to infer appropriate usage from context.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It makes the read-only listing purpose clear and adds the practical nuance about UUID resolution, but does not mention pagination behavior, authorization requirements, or failure modes. This is adequate but not rich.

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

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

Two short sentences with no filler. The core operation is stated first, and the practical use case is given second, making the description immediately scannable.

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

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

Given a fully documented schema, an output schema, and a simple listing operation, the description covers everything an agent needs: what it lists, what the result contains, and why it is useful. No essential context is missing.

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

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

Schema description coverage is 100%, so the parameters are already documented. The description reinforces that project_id selects a project's labels and that outputs are UUIDs for the labels field, but adds no meaning beyond the schema for either parameter.

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

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

The description states a specific verb and resource: "List a project's labels (with their UUIDs)." It also clarifies the purpose of exposing UUIDs, which distinguishes it clearly from sibling tools like create_label and list_work_items.

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

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

The description explicitly tells the agent when to use this tool: to resolve label names to the UUIDs expected by the labels field of work items. It gives clear usage context, though it does not mention exclusions or alternative tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the core action without revealing that it is a read-only operation, that it supports pagination (cursor, per_page), or any other behavior. While the schema hints at pagination, the description adds no behavioral context beyond the bare action.

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

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

The description is a single sentence and is concise, but it essentially restates the tool's name and adds no new information. It is not front-loaded with any important caveats or alternatives. While it is not verbose, it fails to earn its place by providing value beyond the title.

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

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

Given the tool has an output schema and the parameters are fully described, the missing piece is usage context. The description does not mention when to use this tool, whether it is read-only, or any special considerations. For a simple list operation, it is inadequate because it lacks guidance on selecting it over siblings and does not disclose pagination behavior beyond schema defaults.

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 clear descriptions for project_id, cursor, and per_page. The description does not add any parameter-specific semantics, but the baseline is 3 given the schema already covers all parameters. It does not enhance or clarify beyond what the schema 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 'List a project's modules' clearly states the verb and resource, and indicates scope via 'a project's'. It is not a tautology, but it does not differentiate from sibling list tools like list_pages, list_work_items, or list_states, which are similarly named and scoped. It meets the bar for clear purpose but lacks sibling distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives. There is no mention of when to prefer list_modules over other list tools, no exclusions, and no context about typical use cases. The agent is left to infer the purpose from the name and schema 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the tool lists pages in two scopes, omitting any behavioral traits like pagination, default ordering, inclusion of archived pages, or whether the result is a flat list or grouped. The schema covers parameters but not runtime behavior.

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

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

The description is a single, tightly worded sentence that immediately communicates the tool's purpose. It wastes no words and is entirely front-loaded, making it easy to scan.

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

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

With five parameters and an output schema defined, the description is adequate but minimal. The schema covers parameter semantics and the output schema defines the return format. However, the description does not explicitly clarify the default behavior (e.g., that workspace pages are listed when project_id is omitted), relying on the schema's parameter descriptions. It is sufficient for most agent calls but leaves some scope inference to the agent.

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

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

Schema coverage is 100%, so every parameter is already documented in the input schema. The description adds no extra meaning or context about parameters, such as how project_id distinguishes workspace vs project pages, beyond what the schema provides. The baseline of 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 uses the specific verb 'List' and identifies the resource as 'pages', then distinguishes two scopes: workspace wiki pages and project pages. This clearly separates it from sibling tools like get_page (single page) or create_page, though it doesn't explicitly name an 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?

The description provides implicit context for when to use the tool (list pages in either workspace or project scope) but does not give explicit exclusion guidance, such as telling users to use get_page for a single page or to avoid this for detailed retrieval. No alternatives are mentioned.

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

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

No annotations are provided, so the description carries the behavioral burden. It only restates the listing action and does not disclose pagination, default page size, expand behavior, ordering, or whether results are a page of projects. The schema hints at pagination, but the description adds 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?

The description is a single efficient sentence with no filler and is appropriately front-loaded. It is slightly redundant with the title, but it adds the 'in the workspace' 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 list operation with a full output schema and self-documenting parameters, this is minimally viable. However, it lacks guidance on when to use this tool versus get_project and does not mention the paginated nature of results in prose.

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 parameters (cursor, expand, order_by, per_page) are already documented in the input schema. The description adds no parameter-level detail, so it stays at the baseline.

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

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

The description states a specific action and resource: 'List projects in the workspace.' It is clear enough to distinguish from get_project/create_project/update_project, though it does not explicitly name or contrast any sibling tool.

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 choose list_projects over get_project or the other sibling tools. The context is implied by the word 'List', but no exclusions or alternatives are given.

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

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

With no annotations, the description carries the transparency burden. 'List' implies a safe, non-destructive read, and the description adds useful behavioral detail (returns UUIDs and groups, used before state updates). However, it does not mention pagination behavior or any other side effects, leaving some baseline information unstated.

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 concise sentences, each earning its place: the first states the core purpose, the second gives critical usage guidance. No fluff or repetition; the most important information is front-loaded.

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 an output schema and well-documented parameters, the description covers the essential context: what it lists, why it matters, and when to use it. It could be more explicit about being a safe read operation, but the verb 'List' and the absence of destructive language make that reasonably clear.

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 already have clear descriptions. The description adds context about why the output matters (UUIDs needed for state setting) but does not explain the parameters themselves beyond what the schema provides. A baseline 3 is appropriate because the schema does the heavy lifting.

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

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

States a specific verb ('List'), a concrete resource ('a project's workflow states'), and distinguishes itself by mentioning UUIDs and groups. None of the sibling tools share this exact purpose, so an agent can confidently identify it.

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 explicit context: 'Call this before setting the `state` of a work item' and explains why (the API expects a UUID, not a name). This is clear usage guidance but does not explicitly name an alternative tool or discuss when not to use it, hence not a 5.

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

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

With no annotations, the description carries the disclosure burden. It does add one behavioral trait beyond the title ('paginated') and implies a read-only operation via 'List', but it doesn't describe cursor behavior, expand/sort semantics, or any other side effects or requirements.

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

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

A single sentence with no filler. The key information — action, resource, scope, and pagination — is front-loaded and every word earns its place.

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

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

Given the low complexity, full schema coverage, and presence of an output schema, 'List work items in a project (paginated)' is nearly sufficient. The main missing element is routing guidance toward search or single-item alternatives, which was already penalized under usage_guidelines.

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 all five parameters. The description adds no extra meaning beyond the schema, matching the baseline of 3 for fully documented parameters.

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

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

The description states a clear verb ('List'), resource ('work items'), and scope ('in a project'), which distinguishes it from single-item or project-level tools. However, it doesn't explicitly differentiate it from the search_work_items or advanced_search_work_items siblings, so it stops short of a 5.

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

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

There is no when-to-use or when-not-to-use guidance, no reference to alternatives, and no exclusion criteria. An agent is left to infer that this is for the default paginated listing rather than search or filtered retrieval, but nothing in the description says so.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It implies a read-only operation by the word 'list', but does not explicitly state that it has no side effects, nor does it mention authentication, pagination, or permission requirements. However, for a simple listing tool, the lack of these details is not critical, and the output schema likely covers return format.

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

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

Two concise sentences, front-loaded with the main action and a clear use-case sentence. No redundant wording, and every sentence earns its place.

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

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

Given zero parameters and the existence of an output schema, the description covers the essential purpose and usage context. It could mention filtering or pagination behavior, but these are not necessary for a straightforward listing tool. The description is adequate for an agent to decide when and how to call 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?

There are zero parameters, and the schema description coverage is 100% (empty properties). The description adds no parameter details, but none are needed. Baseline for 0 parameters is 4, and the description meets the minimum without requiring clarification.

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

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

The description clearly states the action ('List every member') and the specific resource (members of the configured workspace). It also explains the purpose (resolving names to member UUIDs for the assignees field), which distinguishes it from sibling tools like get_current_user or list_work_items.

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

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

The description gives a concrete use case: resolving names to UUIDs for creating/updating work items. It doesn't explicitly contrast with alternatives, but the context makes it clear when to use this tool. It could be more explicit about when not to use it, but the guidance is sufficient.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the core action and adds 'archived' context, but does not mention side effects, reversibility, permission requirements, or what happens if the page was deleted rather than archived.

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 wasted words. The core scope, 'previously archived page', is front-loaded and every word earns its place.

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

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

For a low-complexity tool with an output schema and fully described parameters, the short description covers the essential use case. It could be slightly richer on behavioral details, but nothing critical is missing for selecting and invoking the tool.

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

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

Schema description coverage is 100%, so the parameters are already fully documented in the schema. The description itself adds no additional meaning about page_id or project_id, so it stays at the baseline of 3.

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

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

The description uses a specific verb, 'restore', and a clear resource, 'previously archived page'. It unambiguously identifies the operation as the reverse of archive_page and distinguishes it from delete_page, create_page, and update_page.

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

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

The phrase 'previously archived page' gives clear context for when to call this tool: only for pages that are archived. It does not explicitly name alternative tools or exclusions, but the condition is implied well enough for an agent to route 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?

There are no annotations, so the description carries the burden of behavioral disclosure. It adds useful context by noting the tool is lightweight and always available and by naming the fields searched, but it does not explain matching semantics, result ordering, or access/rate behavior beyond that.

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

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

Two short sentences with no filler. The core action is front-loaded, and the routing to the alternative tool is stated immediately after.

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 a full input schema, an output schema, and explicit sibling routing, the description is mostly complete for this simple search tool. It could add a little more about matching behavior, but nothing essential is missing for a correct call.

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

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

Schema coverage is 100%, so the schema already documents each parameter. The description adds value by clarifying that `search` applies to names, identifiers, and descriptions, which is meaningful beyond the schema's generic 'Text to look for' example.

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

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

Description opens with a specific verb and resource: 'Search work items by text across names, identifiers and descriptions.' It also differentiates this tool from its advanced sibling, so an agent can tell which search tool to pick.

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 explicitly states this is the lightweight, always-available search and directly routes filter-based queries to `advanced_search_work_items`. This gives clear when-to-use and when-not-to-use guidance.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It only states 'Replace the body,' which implies mutation but does not disclose side effects (e.g., overwriting, permanence), authentication or permission requirements, or any constraints like the comment must exist. It does not describe the return value or any errors, making it opaque for a write operation.

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

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

The description is a single, concise sentence that states the core purpose without waste. It is front-loaded with the action and resource. However, its brevity borders on under-specification—while efficient, it omits critical context that could be included without verbosity, so it does not earn a perfect 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?

Given the tool has 4 required parameters and an output schema (present but not shown), the description is severely incomplete. It does not explain the return value, mention any prerequisites (e.g., the comment must exist), or address the HTML/plain-text behavior described in the schema. For a mutation tool with no annotations, this is far too sparse to guide an agent safely.

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

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

The schema has 100% description coverage for all 4 parameters, so the baseline is 3. The description adds no additional parameter meaning beyond the schema—it does not even reiterate that 'comment' is the new body. Since the schema already documents each field, the description contributes no extra value, but it does not contradict the schema either.

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

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

The description clearly states a specific verb ('Replace') and a specific resource ('body of an existing work item comment'), which distinguishes it from siblings like add_comment and delete_comment. However, it does not explicitly contrast with other update tools (update_project, update_work_item), but since the resource is clearly a comment, it is unambiguous. It does not mention scope (e.g., only for work items), but the resource is 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention that add_comment is for new comments, delete_comment for removal, or any conditions like 'use this when a comment already exists.' There is no explicit context or exclusion, leaving the agent to infer usage from the name alone.

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

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

No annotations are present, so the description must carry behavioral transparency on its own. It discloses that updating replaces the page body and instructs the caller to pass full content, which is a critical side effect. It could additionally clarify behavior when only 'name' is passed, but the main mutation risk is addressed.

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

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

The description is two short sentences with no filler. The action is front-loaded, followed immediately by the most important caveat about body replacement, making every sentence 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 5-parameter mutation tool with full schema coverage and an output schema present, the description covers the essential preconditions and side effects. It would be slightly stronger if it clarified that the body is only replaced when a body parameter is supplied, but the current text is sufficient 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% and every parameter already has a meaningful description, so the baseline is 3. The description adds the rule that at least one update field is required and warns about full-body replacement, but does not substantially enrich individual parameter semantics beyond what the schema provides.

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

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

Description opens with a specific verb and object: 'Update a page's title and/or body' and adds a business rule ('At least one field is required'). It is clearly distinguishable from sibling tools like create_page, delete_page, archive_page, and restore_page by restricting scope to modifying existing page 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?

The intended use is clear: this is the update counterpart to create_page and applies when an existing page's title or content must change. It does not explicitly name alternatives or exclusions, but the update-specific language and body-replacement note provide enough context for an agent to select it.

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

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

With no annotations provided, the description carries the full behavioral burden. It does disclose the partial-update behavior, which is valuable. However, it omits a meaningful behavioral trait: the schema allows null for all editable fields, but the description never clarifies whether explicitly passing null clears a field versus omitting it. Permission requirements and reversibility are also unmentioned.

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 zero filler. The verb, resource, and the key partial-update semantic are all front-loaded before the semicolon, and the clarifying clause earns its place. 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?

The presence of an output schema covers return values, and the description handles the core behavior plus the partial-update nuance. The one notable gap is null-handling semantics (clear vs. leave unchanged), which could cause an agent to set fields unintentionally. For a 6-parameter mutation tool with no annotations, this is mostly but not fully complete.

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

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

Schema description coverage is 100% with each parameter (name, emoji, description, project_lead, default_assignee) documented. The description's partial-update statement aligns with the optional/default-null parameters but adds no per-parameter detail beyond what the schema already provides, 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?

States a specific verb (Update) and resource (project), and crucially discloses the partial-update semantic ('omitted fields are left unchanged'), which meaningfully distinguishes it from create_project and the read-only get_project/list_projects. However, it doesn't explicitly name an alternative or differentiate from sibling update tools like update_work_item or update_comment, 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?

The description gives no guidance on when to use this tool versus alternatives. It doesn't state that it's for existing projects, doesn't name create_project as the choice for new projects, and doesn't mention prerequisites like requiring an existing project_id or project membership. The intended usage is only implied by the tool name and 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does disclose two important behaviors: omitted fields are unchanged, and assignees/labels replace the entire list. However, it does not mention permissions, reversibility, or how to explicitly clear a field, which are relevant for a mutation tool.

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

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

The description is two sentences with no filler. The core behavior is front-loaded, and the critical list-replacement warning is separated and emphasized, making it easy for an agent to parse quickly.

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 rich input schema and output schema, the description covers the key non-obvious semantics. However, it does not explain how to clear a field (e.g., explicit null vs empty array) or provide tool-selection context relative to siblings like create_work_item or delete_work_item, leaving some gaps for a 12-parameter mutation tool.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by clarifying the cross-cutting patch semantics ('omitted fields are unchanged') and emphasizing that assignees/labels must be passed as complete lists, which is not fully captured by individual parameter descriptions.

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

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

The description states a specific verb ('Update'), a clear resource ('work item'), and the exact scope ('provided fields'), making it easy to distinguish from create_work_item, delete_work_item, and get_work_item. The added note that omitted fields are unchanged further sharpens the purpose.

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

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

The description clearly establishes when to use this tool: to modify specific fields of an existing work item. It does not explicitly name alternatives or exclusions, but the context is unambiguous and the replacement caveat for assignees/labels provides practical usage guidance.

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