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

Annotations already declare readOnlyHint=false, so 'This is a write operation' merely restates structured data and adds no value. The description omits genuinely useful behavioral context: whether cancellation is reversible, what happens to a build already completed or queued, what state the build ends in, and any permission requirements.

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

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

Two sentences, front-loaded with the action, but the second sentence duplicates the readOnlyHint=false annotation rather than earning its place. Short but not maximally efficient.

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

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

For a mutation tool with only a readOnlyHint annotation and no output schema, the description should cover side effects, reversibility, and error conditions (e.g., cancelling a non-running build). None of this is present, leaving the agent uncertain about the consequences of 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 buildtarget, build_number, and project are all documented in the schema. The description adds nothing beyond that, which is the correct baseline when the schema carries the full parameter burden.

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

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

States a specific verb and resource ('Cancel a running build'), which is unambiguous against siblings like start_build or get_build. It does not explicitly contrast itself with alternatives, but the destructive verb makes the distinction obvious.

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

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

The description gives no when-to-use or when-not-to-use guidance, no prerequisites (e.g., build must be actively running), and does not reference alternatives such as letting a build finish naturally. Usage must be inferred entirely from the name.

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

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

readOnlyHint=true already declares this a safe read, and the description adds nothing behavioral beyond that — no note on what fields are returned, whether it errors on a nonexistent build, or how the default project is resolved. It neither contradicts nor enriches the annotation.

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

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

A single front-loaded sentence with no filler or padding. It is arguably too terse for the information an agent needs, but nothing present is wasted.

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

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

For a simple read-only lookup with a fully documented schema and no output schema, this is minimally viable. It stops short of clarifying what 'detailed information' contains or how the optional project default behaves, which would help given the absence of an output schema.

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

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

Schema description coverage is 100%, so all three parameters are documented in the schema. The description adds no syntax, format, or defaulting detail beyond 'a specific build', 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?

States a specific verb ('Get') and resource ('build'), and 'specific' plus the required buildtarget/build_number signals it retrieves a single build, implicitly contrasting with list_builds. It does not distinguish itself from get_build_log, which is the nearest sibling overlap.

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?

Purely a statement of function with no when-to-use guidance, no prerequisites, and no routing to alternatives like list_builds or get_build_log. The agent must infer selection from the name alone.

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

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

Annotations declare readOnlyHint=true, so safety is already covered. The description usefully discloses that output is truncated to the last N lines rather than the full log, which is behavioral context beyond the annotation. Beyond that it adds nothing about paging back further or log availability timing.

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 purpose and then the return behavior. No filler or redundant restatement of the tool name.

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

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

For a simple read-only log retrieval tool with full schema coverage, the description covers purpose, scoping, and truncation behavior adequately; the absence of an output schema means return format is only lightly described, which is a minor 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 all four parameters including tail, project, buildtarget, and build_number are documented in the schema. The description's 'last N lines' wording reinforces the tail parameter but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (get) and resource (build log) scoped to a specific build, and clarifies the return shape (last N lines) for failure investigation. It doesn't explicitly differentiate itself from sibling get_build, which returns build metadata rather than the log, but the log-vs-build distinction is reasonably 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 'to help investigate failures' implies the intended scenario (debugging a failing build), which is useful context. However, there is no explicit statement of when to use this versus get_build or list_builds, and no exclusions offered, leaving usage to inference.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds only that filtering exists and that project defaults to the configured default project — useful but thin; it says nothing about result ordering, pagination, or the default page size of 10 beyond what the schema states.

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

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

Two short, front-loaded sentences with no wasted words. It is efficient, though the terseness leaves gaps rather than being optimally informative.

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

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

With no output schema and no required parameters, the description is minimally adequate given 100% schema coverage. However, it omits anything about return shape, pagination, total counts, or ordering, which an agent listing builds would benefit from knowing.

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 four parameters in detail, including default project and per_page limits. The description names two filters (build target, status) that are already fully specified in the schema, adding little beyond it, 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 gives a clear verb+resource ('List builds') and scopes it to a project, plus names the filterable dimensions. It does not explicitly distinguish itself from siblings like list_build_targets or get_build, so it falls 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?

It states what can be filtered but gives no when-to-use guidance, no exclusions, and no routing to alternatives such as get_build for a single build or list_build_targets for target metadata. Usage context is only implied by the tool name and filter mention.

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 readOnlyHint=true annotation already establishes this as a safe read. The description adds the useful default-project fallback behavior, but says nothing about result shape, ordering, or empty-result handling.

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

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

Two short sentences with zero padding, and the core action is front-loaded before the default behavior note. 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?

For a one-optional-parameter, read-only list tool with no output schema and full schema coverage, the description covers what an agent needs. It is slightly thin on how 'build targets' differ from builds, but nothing critical 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 coverage is 100% and the single 'project' parameter is fully documented in the schema, including the default behavior. The description merely restates that default, adding no format or resolution detail beyond the schema.

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

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

States a specific verb+resource ('List build targets') scoped to a project, which is clear enough to separate from list_projects and list_builds. It does not explicitly name the sibling it is not, so the differentiation is left partly to inference.

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 notes the default project behavior, which implies when the argument can be omitted, but it gives no explicit guidance on when to use this tool versus list_builds or get_build. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read-only operation. The description adds no further behavioral context such as pagination, return format, or rate limits. With annotations covering the safety profile, the description adds little, but it is not misleading.

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

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

The description is a single, front-loaded sentence with no wasted words. It clearly states the action and scope, making it highly concise and well-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?

Given the tool has no parameters, no output schema, and simple read-only behavior, the description is adequate but minimal. It lacks details about what a 'project' contains or whether pagination applies, which could help an agent understand the response. However, for a basic list operation, it covers the essential purpose.

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

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

The tool has zero parameters, so there is nothing to document. The baseline for zero parameters is 4, and the description does not need to explain parameters. It correctly implies that all projects are listed without filtering.

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 all projects in the Unity Build Automation organization.' It clearly communicates what the tool returns, but it does not differentiate itself from sibling tools like list_build_targets or list_builds, which also use 'list' semantics. Sibling differentiation is absent, so it falls 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 implies usage by naming the resource (projects in the organization), but it offers no explicit guidance on when to use this tool versus alternatives. With no parameters, there is little ambiguity, yet it fails to mention any prerequisites or contexts like requiring an organization ID. This is the minimum viable level.

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

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

Annotations already declare readOnlyHint=false, and the description's only behavioral claim, 'This is a write operation,' merely restates that. It adds nothing about permissions required, whether the build is asynchronous, whether it can conflict with an in-flight build, or what happens if the target is invalid.

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

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

Two short sentences, front-loaded with the core action. The second sentence is largely redundant with the readOnlyHint annotation, but it costs little and the description is not bloated.

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

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

This is a mutation tool with no output schema and no annotations beyond readOnlyHint=false, so the description must carry more weight. It says nothing about what starting a build returns (e.g. a build ID), whether the operation is async, or how to subsequently track the build via get_build — information an agent would need to use this tool effectively.

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

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

Schema description coverage is 100%, and all four parameters (clean, branch, project, buildtarget) are fully documented with defaults in the schema itself. The description adds no parameter-level meaning beyond that, so the baseline of 3 applies.

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

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

The description names a specific verb ('Start') and resource ('a new build for a build target'), so the agent knows exactly what action is taken. It does not distinguish itself from siblings like cancel_build or get_build, but the purpose itself is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g. the target must exist, must not already be building), and no reference to cancel_build as its counterpart. The agent gets a purpose but no routing context.

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