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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is known. The description adds that it returns only name and type metadata, and points to siblings for other data. However, it does not add deeper behavioral context such as potential errors, response format, or authentication requirements, so it stays at a baseline given the existing annotations.

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

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

The description is two sentences, front-loaded with the core purpose, and immediately directs to alternatives. Every word earns its place, with no fluff or repetition.

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

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

For a simple, one-parameter read-only tool with no output schema, the description is complete: it states what is returned (name, type), identifies the input (by id), and provides navigation to sibling tools for other data needs. No gaps are apparent.

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%: the sole parameter `boardId` has a description ('Board id from RapidBoard.jspa?rapidView=…'). The tool description reiterates 'by id' but adds no extra meaning beyond the schema. Thus, 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 clearly states the tool's function: 'Get Agile board metadata by id (name, type)'. It specifies a specific verb ('Get'), a resource ('Agile board metadata'), and the exact scope ('by id', 'name, type'). It also distinguishes itself from sibling tools by naming alternatives for other use cases.

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 explicit when-to-use guidance: 'For columns use agile_getBoardConfiguration; for daily column dump use agile_getBoardSnapshot.' This tells the agent exactly when to choose this tool over the named siblings, which is clear and actionable.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value by specifying the return contents (ordered columns, status→column map, kanban subQuery, filter) and the mapping behavior, which goes beyond the annotations. No contradictions found.

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

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

The description is two concise sentences, with the main purpose front-loaded. It avoids redundancy and includes only relevant details about the tool's output, making it easy to parse.

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

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

Given no output schema and a simple 2-parameter tool, the description adequately conveys the return value components (columns, status map, subQuery, filter) and purpose. It does not fully describe all possible behaviors, but the schema covers parameters and the description covers the primary output, making it 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 already provides descriptions for both parameters (boardId and resolveStatusNames), covering 100% of parameters. The tool description adds context about the status-to-column mapping, which indirectly clarifies the resolveStatusNames parameter, but does not materially extend parameter semantics beyond the schema.

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

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

The description clearly states the tool retrieves board column configuration with specific components (ordered columns, status→column map, kanban subQuery, filter) and maps issue status IDs to column names. This is a specific verb+resource and distinguishes it from siblings like agile_getBoardIssues or agile_getBoard.

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

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

The description implies usage for retrieving board configuration, but does not explicitly state when to use this tool versus alternatives. No exclusions or alternative tool names are mentioned, so the agent must infer the appropriate context from the description 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?

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the description need not repeat those. It adds valuable context about column placement and JQL subquery interactions, which goes beyond what the schema says and does not contradict the annotations.

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

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

The description is two sentences, front-loaded with the core action, and every clause adds relevant information without redundancy or fluff.

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

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

For a list tool with detailed schema and annotations, the description adequately covers the endpoint, column placement, JQL behavior, and kanban subquery. It does not detail the response structure, but mentions 'column placement' as a hint, and given no output schema exists, this is acceptable. Missing pagination defaults are covered by the schema.

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

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

Schema description coverage is 100%, so all parameters are already documented. The description enriches parameter understanding by explaining that JQL is ANDed with the board filter and that applyKanbanSubQuery defaults to true, providing semantic clarity not immediately obvious from the schema.

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

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

The description clearly states the tool lists issues on an Agile board using the specific REST endpoint, and highlights the column placement feature and JQL integration. It distinguishes itself from sibling board tools (e.g., agile_getBoard, agile_getBoardConfiguration) by focusing on issue listing with status-to-column mapping.

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 how the tool behaves: optional JQL is ANDed with the board filter, and the kanban subquery is applied by default. This helps users understand when to use it, but it does not explicitly mention alternatives or exclusion scenarios, so it falls short of a 5.

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

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

The description discloses meaningful behavioral traits beyond the annotations: default skipping of the 'fabricated kanban Backlog column' and how to use excludeColumns (e.g., for Done). It also hints at size-related behavior via the preference for the ToFile variant. Annotations already declare read-only/idempotent, so these additions are valuable and non-redundant.

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, each with a distinct purpose: purpose, usage, and alternative. No fluff or redundant restatement of schema. Front-loaded with the core function.

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 there is no output schema, the description provides a clear high-level return format ('grouped by columns') which is sufficient for most use cases. It also mentions the default backlog behavior, which is a key edge case. However, it doesn't detail the exact structure of the grouped response, though the tool name and description imply a snapshot of columns→issues.

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 practical semantics for 'jql' (assignee/team filter) and for 'excludeColumns' (e.g., 'Done'), which helps the agent understand how to use these parameters. This extra context elevates the score slightly above 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 clearly states the tool's function: 'issues on a board grouped by kanban/scrum columns (status→column).' It uses a specific use case ('Daily-standup helper') and distinguishes it from siblings by mentioning grouping and referring to agile_getBoardSnapshotToFile for large dumps, setting it apart from agile_getBoardIssues.

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 explicitly gives usage guidance: 'Pass jql for assignee/team filter' and provides an alternative tool for large dumps: 'Prefer agile_getBoardSnapshotToFile for large dumps.' No explicit exclusions, but the alternative suggestion covers the main trade-off.

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 cover readOnly/idempotent/destructive hints. The description adds disclosure of the file-writing side effect and return behavior (path + counts), which is beyond the annotations. This enriches the agent's understanding of what happens.

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

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

Two sentences, front-loaded with the core purpose, and no filler. Every word earns its place.

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

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

The description covers purpose, return shape, and usage context, and annotations provide safety hints. However, with 10 parameters and only 20% schema coverage, the lack of parameter semantics makes the description incomplete for correct tool use.

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

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

Schema description coverage is only 20% (boardId and filePath have descriptions); the remaining 8 parameters are undocumented. The description does not compensate—it only references 'same as agile_getBoardSnapshot' without explaining any parameter details. This is a significant gap for correct invocation.

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

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

The description clearly states the tool writes a board snapshot to a local file, distinguishing it from agile_getBoardSnapshot. It specifies the verb 'writes', the resource 'JSON to a local file', and context 'large boards / daily dumps'.

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 names the alternative tool (agile_getBoardSnapshot) and indicates when to use this variant (large boards / daily dumps) to avoid stuffing full payload into chat. It does not explicitly state when not to use it, but the context is clear.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the API endpoint and the boardId extraction hint, but does not describe the return format or pagination behavior; this matches the 'with annotations' baseline where some extra context is present but not exhaustive.

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: the first states the action and filters, the second gives a practical tip about boardId. Every sentence adds value, and there is no redundancy or 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 read-only list tool with no output schema and 5 parameters, the description covers the core purpose and filtering, while the schema handles pagination and parameter details. The endpoint and boardId tip add useful context, though a note about the return format (array of boards) would have made it 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%, so every parameter is well-documented in the schema. The description's mention of filters ('name substring, type, projectKeyOrId') mirrors the schema without adding new meaning, so it provides little beyond what the schema already communicates.

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

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

The description explicitly says 'List Jira Software boards' and includes the API endpoint, which precisely specifies the verb and resource. It distinguishes itself from sibling board tools by focusing on listing and filtering, not on retrieving a single board's details or 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?

The description clearly explains the filtering options (name substring, type, projectKeyOrId) and even hints at how to obtain a boardId from RapidBoard URLs, which is useful context. However, it does not explicitly state when to use this tool over the other board-related siblings, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by explaining the status-to-column mapping and the check for filter/subQuery match, which goes beyond annotations. It does not detail edge cases like missing issues, but the schema covers the applyBoardFilter 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 two concise sentences: the first states the core action and output, the second gives a practical use case. It 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 tool's moderate complexity, no output schema, and rich parameter schema, the description sufficiently explains what the tool does and when to use it. It does not detail the exact return structure, but that is less critical for a read-only mapping tool, and the schema covers parameter 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 description coverage is 100%, with clear descriptions for all parameters (boardId, issueKeys, applyBoardFilter). The description only references 'board filter/subQuery' without adding new parameter semantics, so the baseline of 3 applies.

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

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

The description uses the specific verb 'Locate' with resource 'issue keys on a board' and clearly defines the expected outcome: mapping each issue status to a column name and indicating whether it matches the board filter/subQuery. This distinguishes it from siblings like agile_getBoardIssues (which likely lists issues) and structure_get (which retrieves structures).

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 a concrete use case ('where is PROJ-1 on the kanban?'), making the intended usage clear. It does not explicitly mention when not to use it or alternatives, but the sibling tools are sufficiently different that the context is evident.

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 indicate a non-read-only, non-destructive operation. The description adds the important default behavior: 'Skips issues already under that parent unless skipIfPresent=false.' It also discloses the API transport (POST action=add), giving the agent context about the nature of the call. No contradiction with annotations.

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

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

Three sentences with no filler. Each sentence adds distinct value: the core action, the API endpoint/action, parent identification, issue identification, and the skip behavior. Front-loaded with the purpose and highly scannable.

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

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

For a mutation tool with 9 parameters and no output schema, the description covers the key decision points: parent selection, issue selection, and idempotency behavior. It does not mention return values or error handling, but the schema details individual parameters and annotations provide safety context. Some gaps remain (e.g., ordering via afterRowId/beforeRowId), but the description is complete enough for correct invocation in most cases.

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 baseline is 3. The description adds combinatory semantics not explicitly in the schema: parent can be identified by underRowId, folderName, or folderId, and issues can be passed via issueKeys and/or issueIds. It also reveals the default of skipIfPresent=true. This goes beyond individual field 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 opens with 'Add one or more Jira issues under a Structure folder (or any parent row)', a specific verb+resource statement that clearly distinguishes this write tool from the sibling list/get/read tools. It also names the API endpoint and action, leaving no ambiguity about the tool's function.

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 practical usage guidance: 'Identify parent via underRowId, folderName, or folderId. Pass issueKeys and/or issueIds.' It does not explicitly mention alternatives, but no sibling tool performs additions, so the intent is clear. It could improve by stating when to prefer underRowId over folderName/folderId, but the schema already notes 'Prefer this when known.'

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, idempotentHint, and destructiveHint=false, covering safety. The description adds meaningful behavioral context by specifying what is included (metadata fields) and what is excluded (hierarchy), which helps set expectations about the response. No contradictions with annotations.

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

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

Two sentences, front-loaded with action and resource, immediately followed by an exclusion and pointers. Every sentence contributes value 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 simple read-only metadata lookup with strong annotations and full schema parameter descriptions, the description sufficiently covers purpose, scope, and exclusions. No output schema, but the description lists the main return fields, making it complete for an agent to invoke.

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 descriptions for all three parameters (withOwner, structureId, withPermissions). The description adds minimal extra parameter information—only implying that the id is the lookup key and listing the owner field, which overlaps with schema. Therefore 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 clearly states a specific action ('Get Tempo Structure metadata by id') and enumerates the returned fields (name, description, owner). It explicitly distinguishes itself from sibling tools by noting it does not include hierarchy and pointing to structure_getForest/structure_getBoard, so the agent can select it correctly.

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 explicitly names alternatives for the excluded case (hierarchy: structure_getForest / structure_getBoard), giving a clear when-not and alternative. The 'by id' usage is implicit in the action, which is sufficient for a simple lookup tool.

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, idempotentHint, and destructiveHint=false, covering safety. The description adds behavioral context about the return format and implies performance characteristics ('fast path'), plus a recommendation for large boards. No contradiction with annotations.

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

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

Two sentences, front-loaded with 'Fast path', zero wasted words. The key purpose and alternative are stated efficiently.

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

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

For a read-only tool with safe annotations and a simple output shape (nested tree), the description provides sufficient context. It names the return fields and points to the large-board alternative, though no output schema exists. Adequate for a fast-path read 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 parameters are fully documented. The description's mention of 'key/summary/status/issuetype' aligns with the schema's default attribute description, adding no new parameter semantics beyond what the schema already provides.

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

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

The description states a specific verb ('read') and resource ('Structure Board'), and details the output format ('nested tree with key/summary/status/issuetype (forest + values)'). It also distinguishes from the sibling tool structure_getBoardToFile, making its unique purpose clear.

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

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

It explicitly states this is the 'fast path' and directs users to use structure_getBoardToFile for large boards, providing a clear alternative. It does not list explicit exclusions but the context is sufficient for selection.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds critical behavioral details: it writes JSON to a local file and returns only path + meta to avoid cluttering chat. This explains the side effect and the response behavior, which goes beyond what annotations indicate.

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, front-loaded with the relationship to structure_getBoard, then the key difference and return behavior. Every word earns its place; no filler or repetition of schema 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?

The tool has 6 parameters and no output schema, but the description explains the return type (path + meta) and the main use case (large boards). By referencing structure_getBoard, it leverages existing documentation for the other parameters. However, it does not clarify the file format or behavior on overwrite, leaving a minor gap for a file-writing 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 50% (only filePath, structureId, and forestSpec have descriptions), and the tool description itself does not explain any parameter. Since this is a variant of structure_getBoard, some parameter meaning might be inferred, but the description does not help with flat, attributes, or includeGenerators. At 50% coverage, the description should compensate but doesn't, leaving agents guessing about several parameters.

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

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

The description clearly states 'Same as structure_getBoard but writes JSON to a local file', identifying both the action (writes JSON to file) and the specific resource (board data). It distinguishes itself from the sibling tool structure_getBoard by explicitly noting the file-writing difference and that it returns path + meta instead of the full tree.

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 direct usage context: 'for large boards', indicating when this tool is preferable. It also implies the alternative structure_getBoard for cases where file output is not needed, though it doesn't explicitly say 'use structure_getBoard when you don't need a file'. This is clear enough for an agent to make a reasonable choice.

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 cover readOnly, idempotent, and non-destructive. The description adds value by disclosing the HTTP method (POST), the return format (formula + parsed flat rows with specific fields), and the fact that it reads the 'latest' forest. It doesn't mention potential pagination or performance, but the added endpoint and output detail go 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?

Two tightly written sentences. The first sentence states the action, endpoint, and return value; the second gives a usage pointer to an alternative. No fluff or redundant information.

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

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

Given the read-only nature, rich annotations, and full schema coverage, the description is complete. It tells the agent what the tool does, what it returns, and when to use a different tool. No output schema exists, so the description's mention of return fields 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% for all three parameters, so the baseline is 3. The description does not add much beyond the schema, only implying that structureId selects the forest. Since the schema already explains forestSpec, structureId, and includeGenerators, the description's contribution is minimal but not absent.

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 'Read' and identifies the resource ('Structure forest (hierarchy)') and even states the endpoint. It clearly distinguishes this tool from the sibling tool by noting 'Prefer structure_getBoard for keys/summaries.'

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 explicitly states when to use this tool (to read the full forest/hierarchy with formula and flat rows) and when to prefer an alternative ('Prefer structure_getBoard for keys/summaries'). It also hints at using forestSpec for transforms/sQuery, giving clear contextual guidance.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive). The description adds the HTTP endpoint (POST /rest/structure/2.0/value) and default attributes, enriching the agent's behavioral understanding beyond annotations.

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

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

Two sentences, front-loaded with the verb and resource, and every sentence contributes useful information. Zero 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?

With rich annotations and full schema coverage, the description covers purpose, prerequisites, and defaults. It lacks an explicit return format, but no output schema exists, so this is not critical. The tool is simple enough that the description is adequately 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 coverage is 100%, so baseline is 3. Description adds value by explaining that row ids come from structure_getForest and that attributes have defaults (key, summary, status, issuetype), which clarifies parameter context without repeating schema details.

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

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

Description explicitly states 'Load Structure attribute values for row ids' with a specific verb and resource. It also distinguishes itself from siblings by referencing structure_getForest for row ids, clarifying the tool's niche.

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 a key usage instruction: 'Get row ids from structure_getForest.' This establishes a clear prerequisite and workflow. It doesn't explicitly mention alternatives to avoid, but for a read-only value loader this is sufficient guidance.

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

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

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds that only boards visible to the user are returned, which is a key behavioral constraint not captured by annotations or schema. No contradictions.

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 compact and front-loaded with the core action and resource. The final sentence about structureId from a JSP URL is a slight tangent, though it offers operational context. Overall, efficient with minimal waste.

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 5 optional parameters and no output schema, the description covers the purpose, endpoint, and a usage hint, but does not mention pagination, default limits, or return format. The read-only annotations reduce risk, and the provided details are sufficient for basic use.

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

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

The schema provides complete descriptions for all 5 parameters, so the baseline is 3. The description's mention of 'name substring filter' only repeats the schema's own description, adding no new semantic value beyond what is already structured.

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

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

The description clearly identifies the tool as listing Tempo Structure boards accessible to the user, using the specific verb 'List' and naming the resource and scope. It distinguishes from sibling tools like structure_get and structure_getForest, which target individual boards or forests.

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 context by stating the user-visible scope and an optional name filter, implying use for discovery. It does not explicitly exclude or name alternatives, but the 'List' vs 'get' distinction in sibling tool names makes the intended use clear.

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 idempotentHint=true, so the safety profile is covered. The description adds value by enumerating the returned fields (rowId, depth, name/summary, folderId), but it does not disclose any additional behavior such as ordering, filtering, or handling of empty structures. Given the annotations cover the main risks, a score of 3 is appropriate.

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

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

The description is one concise sentence plus a short usage clause. It front-loads the verb and resource, lists essential output fields, and includes a practical pointer to another tool—all without 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 simple tool with a single required parameter and no output schema, the description is fairly complete. It states what the tool does, lists the output fields, and gives usage context. However, it does not specify whether folders are returned at all levels or only top-level, and it doesn't describe the structure hierarchy in detail. Still adequate for its simplicity.

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 fully describes the only parameter structureId (100% coverage), so the description does not need to add much. The description mentions folderName and underRowId, but these are output fields, not parameters. Thus it does not enhance parameter understanding beyond the schema, keeping the score 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 clearly states the action ('List folders') and the resource ('Tempo Structure'), and additionally lists the output fields (rowId, depth, name/summary, folderId). It distinguishes from siblings by focusing specifically on folders within a structure, while other tools like structure_list or structure_getForest serve different purposes. The mention of 'Use before structure_addIssues' further clarifies its role.

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 says when to use the tool: 'Use before structure_addIssues to pick underRowId or folderName.' This provides a clear context and a concrete next step. However, it does not mention when not to use it or alternatives, so it stops short of a full 5.

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