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

With no annotations, the description carries the full burden. It discloses that output is limited to the last 100 lines by default and that the latest build is used when buildNumber is omitted, adding behavioral context beyond the schema. However, it does not mention authentication requirements, error behavior, or response format.

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

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

The description is a single sentence that is front-loaded with the action and resource. Every word contributes to the meaning, and there is no unnecessary detail 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 read-only tool with fully described schema, the description is largely complete. The lack of an output schema is mitigated by the self-explanatory 'console output', though the description could be more complete by noting potential error scenarios or the need for prior authentication via sibling login tools.

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

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

Schema coverage is 100%, and the description adds no extra meaning beyond what the parameter descriptions already provide. The mention of 'last 100 lines' and 'latest build' mirrors the schema's lines default and optional buildNumber, but does not enrich the semantic understanding.

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 verb 'Get' and the resource 'console output', with a specific scope of 'specific build or the latest build'. This differentiates it from sibling tools like build_status and build_history, which serve distinct purposes.

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

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

The description implies use when console output is needed, but it does not explicitly state when to use this tool versus alternatives like build_status or job_details. There are no exclusions or alternative references, so guidance is only implicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core behavior (showing builds with status, duration, timestamps) but does not disclose side effects, permissions, error handling, or return format. For a simple read operation, this is adequate but not rich; it adds little beyond the basic function.

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

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

The description is two short sentences, front-loaded with the primary action and resource. It wastes no words and conveys the essential information clearly and 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?

This is a simple read tool with no output schema. The description covers the tool's purpose and explicitly mentions the key output fields (status, duration, timestamps), which compensates for the lack of an output schema. While it doesn't detail exact response structure, it provides enough context for most use cases. The absence of a list of alternative tools 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?

The input schema already provides complete descriptions for both parameters (count and jobName) with details like default and max values. The description refers to 'last N builds' which aligns with the count parameter but adds no new meaning beyond what the schema already specifies. Thus the baseline of 3 is appropriate.

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

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

The description clearly states the specific action: 'Get recent build history for a job.' It identifies the resource (build history) and the key output (last N builds with status, duration, timestamps). This distinguishes it from sibling tools like build_status or build_console, which serve different purposes.

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

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

The description implies usage context: use this tool to retrieve recent build history. However, it does not explicitly mention when to use it over alternatives like build_status or build_console, nor does it provide exclusions or prerequisites. It relies on the reader to infer the appropriate situation.

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 full responsibility. It discloses the return fields (build number, status, duration, displayName, description) and the two operational modes, which provides some transparency. However, it does not mention authentication requirements, error handling, or any side effects, limiting the behavioral detail.

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

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

The description is two concise sentences with no redundancy. The first sentence states the core purpose, and the second lists the returned fields. 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?

This is a simple tool with two parameters and no output schema. The description covers the functionality and explicitly lists the return values, which is sufficient for the complexity. It does not need to elaborate further on errors or prerequisites given the straightforward read operation.

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

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

Schema coverage is 100% with both parameters already described ('Jenkins job name' and 'Build number (omit for latest)'). The description adds context by stating the overall purpose but does not add meaning beyond the schema. Baseline for high coverage is 3.

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

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

The description clearly states a specific action ('Get the status of a build') and resource ('a specific build or the latest build of a job'), and it differentiates from sibling tools like 'job_details' or 'build_history' by focusing on build status outcomes. The return fields (build number, status, duration) are also listed.

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 build status (e.g., 'of a specific build or the latest build of a job') but does not explicitly compare with alternatives or state when not to use it. No prerequisites or exclusions are given, so guidance is only implied.

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 discloses the output format ('table format') and the read-only nature implied by 'Get', but it does not mention authentication requirements, error behavior, or potential side effects. It adds minimal behavioral context beyond the verb and format.

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

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

The description is a single, front-loaded sentence with no redundancy. Every word contributes to explaining the tool's purpose, scope, and output format. It is appropriately sized for a tool with one parameter and one clear action.

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 tool with one parameter and no output schema, the description is mostly complete: it states what is retrieved, for which job, and in what format. The only missing context is authentication prerequisite or behavior when the job does not exist, but these are likely implied by the surrounding tools and context. Overall, it provides sufficient information for selection and 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 coverage is 100% as the sole parameter jobName is documented with a description and an example. The description adds no further semantic value about the parameter itself; 'specific Jenkins job' simply echoes the schema. Thus it meets the baseline but does not exceed it.

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

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

The description clearly states the action ('Get'), the resource ('build parameters'), and the scope ('specific Jenkins job'), with the added detail of 'table format' for output. This unambiguously distinguishes it from siblings like build_status, build_console, and build_history, which cover different aspects of a job.

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 build parameters are needed for a specific job, but it provides no explicit guidance on when to use this tool versus alternatives. There are no references to sibling tools, exclusions, or conditions. The 'specific Jenkins job' phrase hints at scope but does not elaborate on prerequisites or competing tools.

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

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

No annotations are provided, so the description carries the full burden. It discloses the output format ('table format with status') and filtering capability, implying a read-only operation, but does not explicitly state whether it requires authentication, uses cached data, or has side effects. This is acceptable for a simple list tool but not richly 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 description is two short sentences, front-loaded with the primary purpose, and contains no redundant fluff. Every phrase 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 simplicity, a single optional filter parameter, and no output schema, the description covers the essential behavior and output format. It lacks explicit usage guidance relative to siblings, but for a list-all-with-filter tool, it is reasonably 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?

The schema already fully describes the 'filter' parameter, and the description only repeats 'Supports filtering by name' without adding additional semantics. Since schema coverage is 100%, the baseline of 3 applies; the description adds no extra value 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's action ('List all available Jenkins jobs'), the resource (Jenkins jobs), and the output format ('table format with status'). It also mentions filtering, which distinguishes it from more specific tools like job_details or refresh_jobs.

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 viewing all jobs but provides no explicit guidance on when to use this tool versus alternatives like job_details or refresh_jobs. No exclusions or alternative suggestions are given, leaving the agent to infer from the sibling names.

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

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

No annotations are provided, so the description carries full burden. It discloses some behavior: opens browser for new users, validates credentials, auto-discovers jobs. However, it does not explain what happens to an existing session, whether it is safe to call repeatedly, or what side effects occur on failure. Significant gaps remain for a login/mutation tool.

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

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

The description is three short sentences, front-loaded with the main purpose. It includes useful behavioral notes without fluff, though the first sentence 'Login to Jenkins' is somewhat redundant with 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?

The tool has 4 params, no output schema, and no annotations. The description covers purpose and some behavior, but omits return values, error handling, idempotency, and prerequisites (e.g., whether credentials are required). It is adequate but leaves important operational details unanswered.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds minimal context ('Validates credentials' suggests user/apiToken usage, 'auto-discovers all jobs' implies baseUrl) but does not add meaningful details beyond the schema 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 clearly states 'Login to Jenkins' with a specific verb and resource, and adds context 'Opens browser to Jenkins token page for new users' and 'auto-discovers all jobs', which differentiates it from sibling login_slack and other tools.

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

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

The description implies this tool is used for Jenkins authentication, but does not explicitly state when to use it vs alternatives like whoami or logout, nor does it mention when not to use it (e.g., if already logged in). No exclusions or alternatives are named.

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

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

With no annotations provided, the description carries full burden. It discloses that OAuth is used and that a browser opens for authorization, which is valuable. However, it does not explain side effects such as persisting session tokens, how success/failure is signaled, or whether the tool is idempotent. The mention of env vars is a prerequisite, not a behavioral trait. This is adequate but incomplete.

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 concise and front-loaded, starting with the main action 'Login to Slack via OAuth.' It consists of three short sentences, each adding distinct value: the purpose, the mechanism, and the requirements. No unnecessary information is present.

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 zero-parameter login tool, the description covers the essential points: what it does, how it does it, and what is required. It could be improved by mentioning the outcome after login (e.g., that Slack API tools will become usable) or how to handle the browser interaction, but these are inferable from the login context. Overall, it is reasonably complete for the tool's complexity.

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

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

The input schema has zero parameters, so the baseline is 4. The description adds context about required environment variables (SLACK_CLIENT_ID, SLACK_CLIENT_SECRET), which are external prerequisites for invocation. This goes beyond the schema by clarifying the setup needed, though it does not directly explain parameters since there are none.

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: 'Login to Slack via OAuth.' It also specifies the mechanism ('Opens browser for authorization') and resource (Slack), distinguishing it from siblings like login_jenkins. The purpose is unambiguous and specific.

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

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

The description implies when to use the tool (for Slack OAuth login) but does not explicitly state alternatives or exclusions. It mentions required environment variables, which is a prerequisite, but no guidance on when to choose this over other login tools or when not to use it. The usage context is clear from the name and description, but explicit guidance is lacking.

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 states the action but omits important side effects such as irreversibility, impact on active sessions, or what 'jobs' refers to (e.g., queued jobs, cached job lists). This is a destructive operation, and the description does not provide safety context beyond the verb 'clear'.

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

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

The description is a single concise sentence, front-loaded with the action and resource. There is no wasted text, and every word contributes to the meaning.

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

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

The tool is simple with no parameters, annotations, or output schema, so the description is the only source of information. It covers the core action but leaves ambiguity around 'jobs' and lacks detail on consequences (e.g., whether it logs out of all connected services). For a simple tool, this is minimally complete but not fully transparent.

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 schema coverage is trivially 100%. The baseline for 0 parameters is 4, as there is nothing to explain. The description does not need to add parameter semantics because no parameters exist.

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 ('clear') and identifies the resource ('stored credentials and jobs'), clearly distinguishing it from sibling tools like login_jenkins, login_slack, and whoami. The purpose is unambiguous and directly reflects the tool name.

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

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

The description implies usage context but provides no explicit when-to-use or when-not-to-use guidance. Sibling tools like login_* suggest this is the inverse operation, but no alternative or exclusion is mentioned. The guidance is only implicitly derived from the tool name and siblings.

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 is the sole source of behavioral information. It discloses the action ('re-fetch all jobs') but omits potential side effects, prerequisites like login, or whether it modifies cached state. This is insufficient for a tool with no annotation support.

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

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

The description is a single sentence that front-loads the verb and resource, with a brief parenthetical usage note. 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?

The tool is simple (0 params, no output schema). The description provides the core action and a usage trigger. However, it does not disclose what the tool returns or whether it requires prior authentication, which would be useful for an agent. Given the simplicity, the coverage is adequate but not exceptional.

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 no parameters, and the schema is empty. The description adds no parameter-specific syntax, but with 0 parameters, the baseline for this dimension is 4, which 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 identifies the tool's function as re-fetching all jobs from Jenkins, with a specific scoping clause ('use after new jobs are created') that distinguishes it from the sibling 'list_jobs' which likely reads the current list.

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 the tool ('use after new jobs are created'), providing clear context. It does not mention when not to use it or alternatives, so it falls short of full alternative 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 carries the full burden of behavioral disclosure. It states 'Check' which implies a read-only operation, but it does not explicitly confirm that it makes no state changes or network calls, nor does it describe the return format or any potential side effects. This lack of detail is a significant gap.

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

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

The description is a single concise sentence that directly states the tool's purpose. Every word earns its place, with 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?

The tool is extremely simple (no parameters, no output schema). The description adequately conveys the core function but lacks details about the response format or what 'login status' means in terms of output, which could confuse an agent expecting a specific structure. Given the low complexity, it is minimally viable but not 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?

The tool has zero parameters, so per the rubric baseline is 4. The description correctly does not attempt to explain parameters that do not exist, and the schema confirms the absence of 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 uses a specific verb ('Check') and clearly identifies the resource ('current login status for Jenkins and Slack'). It distinguishes itself from sibling tools like login_jenkins, login_slack, and logout by focusing on status verification rather than authentication 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?

The description implies its usage by stating it checks login status, but it does not explicitly state when to use this tool instead of alternatives like 'whoami' or the individual login/logout tools. No exclusions or alternative conditions are mentioned, so guidance is only implicit.

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

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

No annotations are present, so the description must carry the full burden. It only states the action and object, but doesn't disclose side effects (e.g., build process termination), prerequisites (e.g., authentication), or behavior when buildNumber is omitted. This is minimal transparency.

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, well-structured sentence that starts with the verb and contains no redundant information. It is appropriately sized for the tool's simplicity.

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

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

Given the simple nature of the tool and full schema coverage of parameters, the description is minimally adequate. However, the lack of annotations and the omission of any behavioral nuances (like the optional buildNumber semantics in prose) leave it incomplete in a standalone context.

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

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

The input schema already documents both parameters (jobName and buildNumber) with descriptions, achieving 100% coverage. The description adds no additional meaning about parameter usage, so it meets 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 uses the specific verb 'Stop/cancel' with the resource 'a running Jenkins build', clearly identifying the tool's action and object. This distinguishes it from sibling tool trigger_build, which starts 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 description provides no guidance on when to use this tool versus alternatives such as trigger_build or build_status. It neither mentions exclusions nor suggests appropriate contexts, leaving the agent without direction for tool 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?

No annotations are provided, so the description must disclose behavioral traits. It mentions the Slack DM side effect, but omits other important behaviors such as whether the build is triggered asynchronously, requires authentication, or returns a queue item ID. The single side-effect note is insufficient given zero annotation coverage.

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 primary purpose, and the second adds a relevant side effect. No filler or redundant 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?

The description and schema cover the essential invocation details, but without annotations or an output schema, important context is missing: expected return value, whether the call blocks, and prerequisites like login. It is adequate but leaves notable gaps for an agent to invoke safely.

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

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

Schema description coverage is 100%, with all three parameters documented including an example for the nested params object. The description itself adds no parameter semantics beyond what the schema already provides, so 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 the action ('Trigger a Jenkins build with parameters') and includes the resource ('Jenkins build'). This distinguishes it from sibling tools like stop_build, build_status, and job_details, which serve different lifecycle stages.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., being logged in via login_jenkins) or situations where this tool should be avoided in favor of job_details or build_status.

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 states that it retrieves user details from two systems, but does not disclose whether this is a combined call, what happens if the user is not logged in, or any potential side effects. Minimal behavioral information beyond the action itself.

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

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

A single, concise sentence that immediately conveys the purpose. No unnecessary words 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 zero-parameter read-only tool, the description is arguably sufficient, but it omits details about the format of the user details and fails to mention what occurs if the user is not authenticated. The presence of sibling login tools creates context, but the description does not leverage it.

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

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

The tool has zero parameters, so the schema provides complete coverage. The description adds no parameter information, but none is needed. Baseline for no params 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 clearly states the tool's action ('Get') and its resource ('current Jenkins and Slack user details'), which is specific and distinguishes it from siblings like login_jenkins, logout, and status.

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

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

Usage is implied by the standard 'whoami' pattern (check current user after logging in), but there is no explicit guidance on when to use it instead of alternatives like status or login tools. No exclusions or alternative mentions are provided.

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