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

With no annotations provided, the description carries the full burden and excels. It explicitly discloses that certain conditions return an error 'WITHOUT deploying', describes how arguments map to Jenkins parameters, explains wait/timeout behavior, and names the return fields. The two guard clauses are especially transparent about non-obvious failure modes.

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?

Although the description is long, it is densely packed and every section earns its place: a one-line summary, an Args list covering all 11 parameters, and two focused behavioral guard sections. The structure is front-loaded with the high-level purpose, and the error-handling sections are clearly separated for quick lookup.

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 complex 11-parameter deploy tool with no annotations and no output schema, this description is remarkably complete. It covers parameter semantics, job resolution behavior, error conditions with prescribed follow-up actions, waiting behavior, and the expected return fields. An agent has enough information to call it correctly and handle both documented guard failures.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: every single parameter (job, branch, tickets, install_dependencies, use_server_secrets, config_branch, use_dummy_purpose, allow_mr_purpose, extra, wait, timeout) is individually explained with meaningful details like default behavior, fuzzy matching, comma-separated normalization, and mapping to Jenkins-specific parameter names.

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

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

The description opens with 'High-level deploy' and immediately states that it 'maps friendly args to the job's actual Jenkins parameters.' This clearly identifies the verb, resource, and level of abstraction, distinguishing it from lower-level siblings like trigger_build even without naming them. The purpose 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?

The description provides clear operational context for when to use the tool and how to react to its errors: if the deployment purpose is required and missing, ask the user for a ticket or set use_dummy_purpose; if an MR URL is supplied, warn the user and allow allow_mr_purpose as an escape hatch. It does not explicitly name alternatives like trigger_build, but the 'friendly vs. raw' distinction and the extra parameter make the intended usage 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?

With no annotations, the description carries the full burden and discloses useful behavior: one-shot deployment, polling until a build number is assigned, timeout behavior, and environment-scoped defaults. It does not mention auth needs or explicit side effects, but the deploy semantics make mutation evident.

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?

Well structured: a one-line summary, trigger examples, then scannable Args entries. Every sentence adds operational value, and 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 an 8-parameter tool with no output schema and no annotations, this description is nearly complete: it covers usage, defaults, aliases, and polling behavior. The main gaps are the unexplained allow_mr_purpose parameter and the absence of an explicit statement about what the tool returns.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: tickets separators, environment aliases, scope values, branch defaults, install_dependencies override, wait, and timeout are all explained. The only undocumented parameter is allow_mr_purpose, which leaves a real ambiguity.

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 precise verb and resource: 'deploy by ticket URL(s) + environment.' The one-line summary plus concrete examples make it unambiguous what the tool does and distinguish it from generic build/deploy 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?

Includes an explicit 'Use when...' block with realistic user phrasings, so an agent can identify when to invoke it. It does not name alternative sibling tools or explain when not to use this tool, so it stops 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?

With no annotations, the description carries the behavioral burden. It discloses the kind of data returned (result, timestamp, duration, parameters, git), which helps set expectations. However, it does not mention side-effect profile, return format, or error behavior, and it does not explicitly say it is a safe read-only 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, front-loaded sentence that states the core purpose first and then compactly lists the included information categories. 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 simple getter with two clearly named required parameters, the description is minimally adequate. It clarifies the return scope but omits usage heuristics and does not distinguish itself from the many build-related sibling tools, especially the similarly scoped get_last_successful_build and the more specific get_build_log.

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

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

Schema description coverage is 0%, and the description does not explain job_name or build_number beyond the phrase 'a specific build.' The parameter names are somewhat self-explanatory, but the description adds no meaningful detail about how to identify the build, such as the meaning or format of build_number.

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+resource: it returns 'full info about a specific build' and enumerates the content areas (result, timestamp, duration, parameters, git). It is distinct from list-style siblings because it targets a single build, but it does not explicitly name or differentiate from siblings like get_build_log or get_last_successful_build.

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 get_build_log, get_last_successful_build, or get_job_info. The description does not provide context, exclusions, or preference conditions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal the default tail_lines behavior, but it says nothing about output format, error handling, size limits, or the read-only nature of the operation, which would be important for an agent to know.

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

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

The description is extremely concise, with two short sentences that each carry meaningful information. The core purpose is front-loaded, and there is no wasted wording.

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

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

Despite the tool's relative simplicity, the description lacks critical context: it does not state the required parameters, describe the return format, or distinguish itself from sibling tools like get_build_info. With no annotations or output schema, this leaves the agent with significant gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for tail_lines ('Returns the last tail_lines lines by default'), but it does not explain the required job_name and build_number parameters, which are essential for calling the tool correctly.

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 returning console output for a build, using a specific verb ('Returns') and resource ('Console output for a build'). It is distinct from siblings like get_build_info, though it does not explicitly name or contrast them.

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

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

The description implies when to use this tool: when console output for a build is needed. However, it provides no explicit guidance about alternatives, exclusions, or when not to use it, leaving the agent to infer the appropriate 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 bears the burden of behavioral disclosure. 'Get details' implies a read-only operation and the listed fields give some sense of the response, but it does not mention side effects, failure behavior, authorization requirements, or whether any build is triggered.

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

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

The description is a single front-loaded sentence with no filler. Each listed item adds meaningful detail about the return contents, making it efficient and easy 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?

For a simple one-parameter read tool with no output schema, the description gives a reasonable summary of what is returned. It could be more complete by explicitly noting how to refer to the job and by contrasting with build-level tools, but it is adequate for selection and basic invocation.

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

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

The schema only contains job_name, and schema description coverage is 0%, so the description needed to clarify the parameter. It indirectly ties the parameter to 'a job' but never names it, explains its format, or notes that it identifies which job to inspect. The simple parameter name carries much of the weight.

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

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

The description uses a specific verb, 'Get', and names the resource, 'job', with a concrete list of returned contents: description, parameters with defaults, last build numbers, and health. This clearly distinguishes it from build-scoped siblings like get_build_info and get_build_log.

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 says what the tool does but gives no explicit guidance on when to choose it over alternatives, such as get_build_info or list_recent_builds. There are no conditions, exclusions, or references to sibling tools, so the agent has 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 must carry behavioral disclosure; it clearly states that only successful builds are returned and names the included fields. However, it does not cover what happens when no successful build exists or when job_name is invalid, leaving edge-case behavior opaque.

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 the core result front-loaded and the use case in a single supplementary sentence. There is no filler, repetition, or unnecessary detail.

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

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

For a single-parameter read operation with no output schema, the description states the returned fields and the intended deployment-verification workflow. It leaves some gaps around edge-case behavior, but the core invocation context is sufficiently 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?

The required parameter job_name is never mentioned in the description, and the schema provides only a bare title with no property description (0% coverage). The description therefore does not compensate for the missing schema guidance, though the parameter name makes its general purpose somewhat inferable.

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 identifies the operation as retrieving the most recent successful build and enumerates its contents (timestamp, duration, parameters, git info). The 'SUCCESSFUL' qualifier and 'last' distinguish it from siblings such as get_build_info or list_recent_builds.

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 'Primary use case' sentence provides a concrete scenario—comparing the returned timestamp against a GitLab MR merge time to verify deployment—so an agent knows when to use this tool. It does not explicitly name alternatives or exclusion cases, so it stops short of full 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?

No annotations are provided, so the description must carry the burden. 'List items currently waiting' clearly implies a read-only operation and a specific state, but it does not disclose ordering, pagination, or what happens when the queue is empty. The output schema may cover return shape, but behavioral details are limited.

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

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

The description is a single, efficient sentence that states the action and the target directly. Every word adds value and there is no redundant information.

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

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

For a parameterless, read-only listing tool with an output schema, the description is largely sufficient. The only gap is the lack of explicit guidance about how it differs from get_queue_item, but given the low complexity this is a minor omission.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is no parameter information missing. The description adds no parameter details, but none are needed. The baseline for zero-parameter tools is 4.

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

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

The description uses a specific verb ('List') and a clear resource ('items currently waiting in the build queue'). It clearly communicates what the tool does and distinguishes it from get_queue_item, which implies a single item lookup.

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

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

The description implies when to use it: when you want a list of currently waiting build queue items. However, it does not explicitly mention alternatives like get_queue_item or clarify when to use one over the other, leaving some inference to the agent.

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. The verb 'Poll' implies a read/status-check operation, and the mention of wait=False adds useful async context, but the description does not state what the response contains, whether it blocks, or whether it can be safely called repeatedly. Some behavior is inferable, but not explicit.

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 no filler. It front-loads the action and resource, then adds the key provenance detail in a compact em-dash clause. Every part 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 simple one-parameter tool, the description gives good provenance for the input but omits what the agent can expect as output or how to interpret the poll result. Since there is no output schema or annotations to fill that gap, the description is somewhat incomplete for fully confident invocation.

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

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

The input schema only says queue_url is a required string with 0% schema description coverage. The description compensates by explaining that this URL is the queue item URL returned by trigger_build/deploy when wait=False, giving the parameter operational meaning beyond the schema.

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

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

The description uses a specific verb ('Poll') and a specific resource ('a single queue item URL'), and clearly distinguishes it from the broader get_queue tool. It also states the exact source of the URL, which removes ambiguity about what the tool acts on.

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 the scenario in which this tool should be used: when trigger_build or deploy is called with wait=False and returns a queue URL. It does not name alternative tools or exclusions, but the context is clear enough for an agent to select it 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?

With no annotations provided, the description carries the full behavioral burden. It adds useful context by disclosing the matching mechanism (ticket URL matched in MR title/description) and requiring a 'Full URL'. It does not, however, disclose edge-case behavior such as empty results on no match, invalid URL handling, or explicitly confirm the operation is a safe read—though 'Find' strongly implies it.

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 compact components: a front-loaded purpose sentence followed by a tight Args section. Every line earns its place—there is no filler, marketing language, or redundant restatement of the schema.

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 2-parameter read-only lookup with no output schema, the description covers purpose, matching behavior, and all parameter semantics—nearly everything an agent needs. The main gap is that it never states the return shape (a list of MRs is implied but not explicit), and there is no annotation layer to fill in safety or edge-case details.

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

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

Schema description coverage is 0%, so the description must fully compensate, and it does: ticket_url is defined as 'Full URL of the GitLab ticket/issue' and state is documented with its exact allowed values ('all' | 'opened' | 'merged' | 'closed') and default. This adds real meaning beyond the bare schema, which only lists names, types, and a default.

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, resource, and scope: 'Find MRs linked to a ticket URL (matched in MR title/description)'. This clearly distinguishes it from sibling tools, which all concern jobs, builds, and deployments rather than ticket-linked merge requests.

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

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

Usage context is implied by the tool's purpose—use it when you need MRs associated with a GitLab ticket—but there is no explicit when-to-use guidance or naming of alternatives. The ticket-related siblings (deploy_tickets, is_ticket_deployed) are different enough in function that no confusion seems likely, yet the description does not route the agent away from them.

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

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

With no annotations, the description carries the transparency burden. It discloses the core comparison semantics and the accepted ISO 8601 forms, but it does not state the return type/boolean result, behavior when no successful build exists, or whether this is strictly read-only.

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: the first sentence states the operation, and the two follow-up sentences add the intended use case and timestamp format. 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?

Adequate for a simple predicate tool, but incomplete around edge cases: return format is not described (no output schema), and there is no guidance on nonexistent jobs or missing successful builds. It also does not mention whether job_name must be pre-resolved via resolve_job_name.

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

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

Schema description coverage is 0%, so the description must add meaning. It does: merge_time_iso is explained as an ISO 8601 timestamp with concrete examples, and job_name is tied to the job whose last successful build is checked. It leaves job_name identification implicit but is sufficient for a two-parameter tool.

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 predicate: it checks whether a job's last successful build ran after a supplied ISO timestamp. It names the resource and the operation, but it does not distinguish itself from siblings like is_ticket_deployed or get_last_successful_build.

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 includes an explicit intended use case ('was this GitLab MR deployed?') that tells an agent when this check is relevant. It does not state when not to use it or mention alternative sibling tools for similar ticket or deployment checks.

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

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

No annotations are present, so the description carries the full behavioral burden. It discloses the classification rule for frontend vs backend, the ancestor-of-deployed-branch check tied to Jenkins build type, per-MR reporting, the aggregate 'deployed' rule, and separate handling for unmerged MRs. This is exceptionally transparent.

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

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

The purpose sentence is front-loaded, followed by a compact bulleted breakdown. Every bullet adds a distinct behavioral or semantic fact, with no redundant or filler content for a tool with this much internal logic.

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 does a good job of covering return semantics: per-MR deployed=true/false with reasons, unmerged MRs reported separately, and the overall ticket criterion. It lacks explicit parameter examples and does not state prerequisites or error behavior, which keeps it just short of 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 0%, so the description must compensate. It indirectly defines environment via 'dev or stage' and uses `<env>` in build-name templates, and it clarifies that ticket_url identifies the ticket whose merged MRs are examined. However, it never gives the exact expected URL/format or a formal enum for environment, so compensation is only partial.

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+resource: 'Verify whether a ticket's merged MRs are deployed on dev or stage.' It also goes further to define exactly what 'deployed' means, distinguishing the tool from siblings like get_ticket_mrs (which returns MRs) and is_deployed_since (a time-based check).

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 for use is clear: call this when you need a ticket-level deployment verdict covering all merged MRs. It does not name alternatives or exclusions explicitly, but the detailed coverage criteria make the intended usage unambiguous, meeting the 'clear context, no exclusions' bar.

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 but stays minimal. It does disclose that the result is grouped by specific environment categories and includes last build time and status. It does not discuss read-only behavior, authentication, empty results, or ordering, but for a simple list tool the core behavioral traits are visible.

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 dense sentences: the first front-loads what the tool does, the second adds the usage trigger and the return grouping categories. There is no filler or repeated information from the schema.

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 list tool with no output schema, the description provides the essential usage context and return-group information. It is complete enough to call correctly and interpret the result, though a bit more detail about the output shape or edge cases could push it to 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?

The tool has zero parameters, so there are no parameter semantics to clarify. The baseline for 0 params is 4, and the description appropriately avoids inventing unnecessary parameter 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?

The description clearly states a specific verb ('List'), a specific resource ('deployment-type jobs'), and a distinctive grouping ('by environment, with last build time + status'). This differentiates it from the sibling list_jobs, which presumably lists all jobs, and from deploy actions.

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 says 'Use this to discover what you can deploy,' giving agents a clear trigger condition for selecting this tool. It does not mention when not to use it or name alternatives, but the context is clear enough.

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 adds the meaningful detail that an empty folder returns the root listing, but it does not describe the output shape, pagination, or whether nested folders are traversed. Still, 'List' clearly implies a read-only 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?

Two concise sentences with no filler. The main action is front-loaded and the parameter guidance is directly actionable.

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

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

For a simple list tool with one optional parameter and an output schema present, the description is largely complete. It covers the core action and the parameter's semantics, though it could slightly benefit from noting whether the folder path is absolute or relative.

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

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

Schema coverage is 0%, so the description must compensate. It explains the only parameter, `folder`, with a concrete path example ('team/sub') and the empty-default behavior, adding meaning beyond the plain schema string type.

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

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

The description states a specific verb and resource: 'List Jenkins jobs.' It also quickly explains the folder-scoping behavior, which helps distinguish this tool from job-specific siblings like get_job_info or trigger_build.

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 explains how to use the folder parameter ('Pass folder... empty lists root'), which is useful usage guidance. However, it does not explicitly state when to prefer this tool over alternatives or mention any 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only states the content of the response (timestamps, durations, results) but does not mention ordering, whether the list is newest-first, default limit behavior, or any error/edge cases. A 'list' operation is implicitly read-only, but the description adds minimal 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 that directly states the tool's purpose and the key fields included in the results. It is concise and front-loaded with the action, though it could have added brief parameter clarification without losing structure.

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 relatively simple (2 params, no nested objects) and an output schema exists, so return values are covered by structure. However, the description omits ordering semantics and the meaning of 'recent' (e.g., descending by timestamp), and does not clarify how limit behaves. These gaps leave an agent to infer important details.

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

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

Schema description coverage is 0%, and the description does not explain either parameter (job_name or limit). The phrase 'for a job' loosely hints at job_name but gives no detail about the limit parameter or how it affects results. The description fails to compensate for the uninhabited schema.

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

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

The description uses a specific verb ('List') and resource ('recent builds for a job'), and clarifies that the response will include timestamps, durations, and results. This distinguishes it from sibling tools like list_jobs (which lists jobs) and get_build_info (which retrieves one build).

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

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

The description implies usage when you need a history of recent builds for a specific job, but it does not explicitly state when to avoid this tool or name alternatives such as get_last_successful_build or get_build_info. No exclusions or conditions are provided.

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

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

With no annotations, the description carries the behavioral burden. It discloses that the tool performs fuzzy matching and returns both the matched job and close candidates, which is useful. However, it does not mention side effects (or the absence of them), error behavior when no match is found, or any auth/rate-limit considerations. 'Show' implies read-only but it is not explicit.

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 no filler. It front-loads the key trigger ('Given a rough name') and then states the expected output. Every clause 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?

This is a simple one-parameter tool with no output schema and no annotations. The description explains what input is expected and what will be returned, which is enough to make the first call. Minor gaps like no-match behavior and explicit read-only confirmation exist, but they do not block correct usage.

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

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

Schema description coverage is 0%, so the description must clarify the parameter. It does: 'query' is a rough job name, with the example 'dev backend'. This adds meaning beyond the bare schema which only labels the field 'Query'. It could be more detailed (e.g., case sensitivity, matching rules), but for a single string parameter it is sufficient.

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 ('resolve') applied to a resource ('job name') and defines the expected output: the matched job and close candidates. The example 'dev backend' and the focus on fuzzy matching distinguish it from siblings like list_jobs and get_job_info.

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 'Given a rough name' gives clear context for when to use this tool: when the job name is approximate or partial. It does not explicitly name alternative tools or state exclusions, but the usage scenario is clear enough for an agent to select it appropriately.

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 does disclose the queue-polling behavior and wait default, which is useful. However, it does not explain what happens on timeout, what wait=False does, what the tool returns, or any prerequisites/auth requirements.

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

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

The description is three concise sentences with no filler. The first sentence states the core purpose, the second adds a key behavioral detail, and the third routes to the right sibling alternative.

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

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

With no output schema and no annotations, the description should cover return behavior and side effects more fully. It does not mention what the tool returns, the behavior when wait=False, or what happens when the timeout expires. The description is a good start but not complete enough for confident 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 0%, so the description must compensate for explaining parameters. It adds meaning for `parameters` by saying they use raw Jenkins names and confirms the `wait` default. But it does not describe `timeout` semantics/units or the required `job_name` 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 uses a specific verb and resource, 'Trigger a build,' and immediately clarifies that it operates on raw Jenkins parameter names. This distinguishes it from the higher-level deploy sibling, so an agent can tell what the tool does and how it differs.

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 when to use this tool versus the alternative: if a higher-level deploy with friendly names is needed, use deploy(). It also clarifies that wait=True is the default and polls the queue, giving clear context for invocation.

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 clearly discloses that the tool blocks and polls until success or timeout. It does not explain return values, timeout error behavior, or side effects, though the core polling behavior is transparent enough.

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

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

One sentence that front-loads the action and termination condition, with no filler or repetition. 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 tool with no annotations and no output schema, the description is too thin: it omits what the tool returns, what happens on timeout, the units of timeout, and any prerequisite (e.g., where queue_url comes from). These are material gaps for an agent invoking it 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?

Schema description coverage is 0%, so the description must compensate for parameter meaning. It only echoes 'queue URL' and 'timeout' without adding units, format, or timeout semantics, leaving the agent to guess details like whether timeout is seconds.

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: block-polling a queue URL until a build number is assigned or a timeout occurs. This clearly identifies the tool's resource and termination condition, and separates it from sibling get/list/trigger 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 intended use is implied: use this when you need to wait for a build number rather than manually polling a queue. However, there is no explicit guidance about when not to use it, what alternative to choose instead, or how the queue URL should be obtained.

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