Hacker Bob public records

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

Annotations already establish readOnly=false, destructive=false, and idempotent=true. The description adds the non-obvious behavioral trait that no assessment is started and that the tool only creates a proof-of-control challenge. It does not contradict the annotations.

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

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

Two sentences with no filler. The core action is front-loaded, and the clarifying statement that this does not run an assessment earns its place by preventing confusion with sibling assessment tools.

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 creates a challenge artifact, but the description does not state what is returned (e.g., TXT record value, file contents) or what the user should do next (e.g., publish the challenge and then use check_domain_authorization). With no output schema, this is a meaningful gap, though the description is still sufficient for selecting the tool correctly.

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

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

Schema description coverage is only 40%: domain and workspaceSlug have descriptions, while method, idempotencyKey, and label do not. The description maps the method enum values to plain language ('DNS TXT' and 'HTTPS-file'), but it does not explain the purpose of idempotencyKey or label, so compensation for the low schema coverage 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 states a specific action ('Create'), a concrete resource ('DNS TXT or HTTPS-file challenge'), and the purpose ('proving control of a domain'). It also disambiguates from assessment tools with 'This does not run an assessment.'

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

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

The description gives clear context: use this tool when you need to prove domain control via a challenge. It also provides an explicit when-not by stating that it does not run an assessment, which separates it from launch_assessment. However, it does not explicitly mention check_domain_authorization as the follow-up verification tool or name other alternatives.

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 convey destructiveHint=true and idempotentHint=true; the description adds two useful behavioral specifics beyond that — cancellation applies only to queued/running eligible assessments, and the operation reconciles refundable reserved credit. It does not contradict the annotations.

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

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

A single sentence front-loads the primary action and packs in eligibility scope plus the credit side effect without waste. Every clause earns its place, and it is appropriately sized for an action tool.

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

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

The description covers the core action, state constraints, and the credit side effect, but with no output schema it leaves success/error return behavior unexplained, and it never addresses the three required parameters — especially idempotencyKey, which is mandatory. 'Eligible' is also left undefined. Adequate but with clear 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 only 33%, with assessmentId and idempotencyKey left undoced in the schema. The tool description does not compensate: it never explains how to obtain assessmentId or how to generate and use idempotencyKey. The required idempotencyKey parameter in particular has zero guidance.

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 ('cancel') and resource ('assessment'), and adds state scope ('queued or running') plus the credit-reconciliation side effect. The action is clearly distinct from sibling tools like launch_assessment, prepare_assessment, get_assessment, and list_assessments.

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 'eligible queued or running' gives implied context that completed assessments are not valid targets, but the description never explicitly states when to use this tool versus alternatives or suggests checking status first via get_assessment. No exclusion or alternative-routing guidance is 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?

Annotations already indicate the operation is not read-only, is idempotent, and is not destructive. The description adds concrete context by saying it checks a DNS or HTTPS proof and updates the authorization state, which explains the mutation beyond the annotation flags. There is no contradiction with annotations.

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

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

The description is a single front-loaded sentence with no filler. It communicates the core action, the object of the action, and the resulting state change 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?

Given the low parameter schema coverage, three required parameters, and no output schema, the description leaves important invocation details unexplained. An agent would not know the semantics of authorizationId or idempotencyKey, nor exactly when to call this tool relative to begin_domain_authorization.

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

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

Schema description coverage is only 33%, with workspaceSlug described but authorizationId and idempotencyKey left undocumented. The description does not explain what authorizationId represents or how idempotencyKey is used, so it fails to compensate for the large schema coverage gap.

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 ('Check') on a specific resource ('previously issued DNS or HTTPS proof') and includes the resulting state transition ('update the asset authorization state'). It is clearly distinguishable from the sibling begin_domain_authorization, which would be the initiation step.

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

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

The phrase 'previously issued' implies this tool should be used after a DNS or HTTPS proof has been created, but it does not explicitly say 'use after begin_domain_authorization' or contrast with alternative tools. No direct when-not guidance is provided, so usage 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?

Annotations already convey readOnly, idempotent, and non-destructive behavior. The description adds useful context by exposing that the tool returns 'current run state' and 'pending human approval', revealing stateful workflow info beyond what annotations state. No contradictions with annotations.

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

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

The description is a single, tightly written sentence with no filler. The core action ('Return one assessment') is front-loaded, and each listed detail earns its place by clarifying the return payload.

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, the description compensates by summarizing the main return components. The required parameters are clear from the schema, and the tool's scope is well covered. It omits edge cases like not-found behavior, but that is minor for a simple read-only getter.

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

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

Schema coverage is 50%, with workspaceSlug described but assessmentId not. The tool description adds no parameter-level explanation, though 'assessmentId' is fairly self-explanatory alongside 'one assessment'. It does not worsen the gap but also does not compensate for the missing schema description.

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, 'Return', with a clear resource ('one assessment') and enumerates the distinct elements returned (verified asset, current run state, pending human approval). This clearly distinguishes it from siblings like list_assessments (plural collection) and get_asset/get_finding (different resources).

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 a single assessment's status/detail is needed, especially given the assessmentId parameter, but it does not explicitly state when to prefer this over list_assessments or other assessment-related tools. Usage is inferred rather than directly guided.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered externally. The description adds that the result includes the 'current authorization state', which is useful behavioral context, but it does not explain what that state contains or what happens for missing or unauthorized assets.

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 short sentence with no filler. The key differentiating facts—'one workspace asset' and 'current authorization state'—are front-loaded and every word contributes.

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 two required parameters and a rich safety annotation set, the description covers the core purpose and return focus. The main gap is the absence of an output schema and lack of detail about the authorization-state payload, but these are minor given the tool's simplicity.

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

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

The schema describes workspaceSlug but leaves assetId undocumented, and the description does not compensate by explaining either parameter. With only 50% schema description coverage, the description should add meaning for assetId, but it only refers vaguely to 'one workspace asset'.

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

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

The description states a specific action ('Return'), a specific resource ('one workspace asset'), and a distinguishing detail ('its current authorization state'). It clearly contrasts with list_assets, which returns multiple assets, and with get_workspace, which targets workspace metadata.

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 for retrieving a single asset by ID within a workspace, but it does not explicitly name alternatives like list_assets or get_workspace, nor does it state when not to use this tool. The agent must infer usage from the singular wording and sibling tool 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?

Annotations already mark the tool as readOnly, idempotent, and non-destructive, so the description is not burdened with repeating those. It adds valuable behavioral context by explaining the authentication-dependent behavior: public boundaries are always returned, while workspace-specific details appear only when authenticated.

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, well-structured sentence front-loads the main purpose ('Return current public boundaries') and then appends the conditional authenticated portion. No filler or repetition of annotation metadata.

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 no-parameter, read-only introspection tool, the description covers the essential information: what is returned and how it varies by authentication state. There is no output schema, but the description enumerates the returned categories well enough for an agent to know what to expect. Minor ambiguity around the exact meaning of 'public boundaries' prevents 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 takes zero parameters, so the description carries no parameter documentation duty. The baseline for a zero-parameter tool is 4, and the description appropriately focuses on output semantics rather than parameters.

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

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

The description states a specific verb ('Return') and resource ('capabilities'), and details exactly what is returned: public boundaries plus, when authenticated, workspace-specific tool reachability, scopes, and role requirements. This clearly differentiates it from sibling tools that operate on assessments, assets, findings, or workspaces.

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

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

The description gives clear context for when to use the tool: to retrieve current public boundaries and, after authentication, workspace-specific permissions and reachability. It does not explicitly name alternatives or when-not-to-use, but the unique purpose makes the usage scenario apparent.

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 and idempotentHint, so the safety profile is covered. The description adds value by specifying the exact data categories returned (available, reserved, used), which is behavioral context beyond the annotations. It does not discuss error behavior or meaning of 'reserved,' but for a simple read-only summary this is adequate.

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 redundant words or repetition of the title. It efficiently communicates the action, resource, and scope.

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

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

For a one-parameter, read-only tool with strong annotations, the description is largely complete: it states what is returned and the scope. It does not describe output format, but no output schema exists and the simple credit summary result is sufficiently implied by the description.

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 the workspaceSlug parameter already has a clear description in the schema ('Workspace slug selected during agent authorization'). The tool description adds no extra parameter-level meaning, but the baseline of 3 is appropriate since the schema fully documents the 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 ('Return') and names a precise resource ('available, reserved, and used assessment credits') scoped to 'the approved workspace.' It clearly distinguishes this tool from sibling get_* tools such as get_assessment and get_workspace.

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 to check credit status for the approved workspace, but it does not explicitly state when to use it versus alternatives or mention any exclusions. There is no guidance on scenarios like pre-launch credit validation or why one would call this instead of launch_assessment.

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

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

The annotations already cover the safety profile with readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate those. It adds that the result includes lifecycle history and asset metadata, but it does not clarify what 'evidence-safe' means or describe auth or error behavior. There is no contradiction with the annotations.

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

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

One direct sentence with the key scope front-loaded and no filler. It communicates the main purpose without wasting words, which is appropriate for this tool.

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 two required parameters and strong annotations, the description is nearly sufficient: it names what is returned and the scope. It is slightly cryptic about 'evidence-safe lifecycle history' and does not describe the exact return shape, but given the low complexity and available schema, this is acceptable.

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

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

Schema description coverage is only 50%: workspaceSlug has a description, but findingId has none. The tool description does not compensate by explaining findingId's meaning or constraints beyond implying it identifies the finding. The agent is left without adequate parameter-level guidance for one of the two required arguments.

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

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

The description states a specific action ('Return') and resource ('one finding'), and it adds scope ('evidence-safe lifecycle history and related asset metadata') that helps separate it from list_findings and get_asset. It is not as explicit as the strongest examples, and 'evidence-safe' is somewhat jargon-heavy, but the core purpose is clear.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The singular 'one finding' and the required findingId imply this is the detail-retrieval counterpart to list_findings, but the description leaves that 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds context by specifying that the workspace is 'bound to this agent connection,' which clarifies scoping beyond the annotations.

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

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

The description is a single sentence that front-loads the action and resource with no filler or redundant information. Every word adds 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?

For a zero-parameter, read-only, idempotent operation, the description fully specifies what is returned and the scope of the result. No output schema exists, but nothing critical is missing for an agent to invoke this correctly.

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

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

The tool has zero parameters, so there is no parameter semantic burden on the description. Per the baseline rule, a score of 4 is appropriate because no parameter documentation is needed.

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

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

The description names a specific verb ('Return') and a unique resource (the authenticated account plus its bound workspace), making the function's purpose clear. However, it does not explicitly distinguish itself from sibling tools like get_workspace or list_workspaces, though the 'bound to this agent connection' phrase provides some differentiation.

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

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

The description clearly indicates the context: obtaining the authenticated account and its workspace. It does not list alternatives or exclusions, but the zero-parameter nature and specific resource make the usage context reasonably obvious.

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

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

The annotations already disclose readOnly, idempotent, and non-destructive behavior. The description adds useful context about what fields appear in a successful result and explicitly caveats that the upstream URL is included 'when available'. It does not describe behavior for unknown identifiers or auth, but annotations carry the safety burden well.

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 informative sentence that leads with the core action and outcome, then lists the key return fields. No words are wasted, and the essential 'by identifier' scoping is up front.

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 single-record read-only getter, the description is quite complete: it names the identified, the returned context, and one conditional absence. Missing behavior around invalid or not-found identifiers is a minor gap, especially with no output schema present.

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 covers the sole parameter recordId completely with a pattern and an example. The description reinforces that the record is retrieved by identifier but does not add any semantic detail beyond what the schema already provides. With full schema coverage, the baseline score of 3 is appropriate.

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

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

The description clearly states the tool's specific action—'Return one cleared Hacker Bob CVE record by identifier'—and describes what is included. The singular 'one' and reference to a specific record immediately distinguishes this from the plural list and search tools among its 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?

The description clearly implies this tool is for fetching a single record when an identifier is available, but it does not explicitly say when to use the list or search siblings instead. There is no exclusionary guidance such as 'when you don't have a CVE ID, use search instead'.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds meaningful behavioral context beyond annotations by stating that only released, non-revoked reports are returned and that pending review material and access credentials are never returned. This helps the agent set correct expectations about response content.

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

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

The description is two short sentences with no wasted wording. The core purpose is stated first, followed by a valuable exclusion clause. 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 simple two-parameter getter with strong annotations, the description covers the essential retrieval scope and content exclusions. It does not describe return fields or error behavior, but the absence of an output schema and the tool's simplicity make the description sufficiently complete for correct invocation.

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

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

Schema description coverage is only 50%: workspaceSlug is documented, but reportId only has length constraints and no semantic explanation. The description does not compensate by explaining how reportId is structured, obtained, or used to select a specific report.

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: 'Return one released, non-revoked workspace report.' It clearly differentiates this single-report getter from sibling tools like list_reports and get_finding. The qualifiers 'released' and 'non-revoked' add precise scope.

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 conveys that this is for retrieving a single released report and that pending or sensitive material will not be returned. It does not explicitly mention when to prefer list_reports or other alternatives, but the single-item and status constraints give clear contextual guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful context beyond that by specifying the workspace is 'approved' and that the response includes the membership role, though it does not disclose error behavior or authorization failure 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?

The description is a single, focused sentence with no filler. It front-loads the core purpose and return content, which is appropriately sized for a one-parameter, read-only getter.

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 one well-documented parameter and strong annotations, the description covers the essential return value and authorization scope. It falls slightly short of 5 because it does not mention potential error conditions or explicitly connect usage to the authorization flow beyond the schema's parameter description.

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 single parameter workspaceSlug has 100% schema description coverage, including its pattern, length limits, and authorization context. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate because the schema carries 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 ('Return') and resource ('workspace'), and adds meaningful scope ('approved') and return content ('current membership role'). This clearly distinguishes it from sibling tools like list_workspaces, which would return a collection rather than a single workspace with role information.

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 only implied: an agent would use this when it needs the approved workspace and the current membership role. There is no explicit statement of when not to use it or which alternatives exist, but the resource and context are clear enough to infer the basic trigger.

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 signal destructive and non-read-only behavior; the description adds that the submission is immutable, consumes a prior approval, and resolves the target only from stored data. It doesn't detail exactly what destruction occurs, but that is adequately implied by 'consume' and the destructiveHint 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?

Two tight sentences, front-loaded with the action and prerequisite. No filler; each clause adds a meaningful constraint or behavioral 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 three-required-parameter mutation with no output schema, the description plus annotations cover the prerequisite, target derivation, immutability, and queue destination. The only notable omission is explicit idempotencyKey guidance, but the parameter name and idempotentHint annotation mitigate that 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?

At only 33% schema description coverage, the description partially compensates: 'recent human approval' tells agents assessmentId must refer to an approved assessment, and 'target resolved only from stored verified asset' explains why no target parameter should be supplied. However, idempotencyKey semantics are left entirely to the parameter name and annotation, so the description does not fully carry the parameter-documentation 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?

Description uses specific verbs ('consume', 'submit') and identifies the resource ('assessment', 'managed queue') and condition ('approved', 'recent human approval'). It distinguishes launch_assessment from prepare/cancel/get/list siblings by emphasizing immutable final submission.

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 establishes when to use: after a recent human approval, and clarifies no target parameter should be used because the target comes from the stored verified asset. It doesn't explicitly name siblings like prepare_assessment or cancel_assessment as alternatives, 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the useful behavior that returned data includes current run states, but it does not disclose pagination, default filtering of archived items, or any other behavioral traits. No contradiction exists between description and annotations.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes: the action, the resource, the additional run-state detail, and the workspace scope.

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

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

For a read-only list operation with a simple schema, the description plus annotations are mostly adequate, but gaps remain: includeArchived is unexplained, there is no mention of pagination, and the absence of an output schema means the exact return shape is only loosely implied by 'current run states.'

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 only 50%: workspaceSlug is described, but includeArchived has no schema description. The tool description does not mention either parameter or explain the meaning of includeArchived, so it fails to compensate for the undocumented optional 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 ('List') with a clear resource ('assessments') and adds a distinctive scope element ('current run states'), which separates it from the single-item get_assessment and from action-oriented siblings like launch_assessment or cancel_assessment. The scope 'in the approved workspace' further clarifies what is being 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 that the tool should be used to list assessments within an approved workspace, but it does not explicitly say when to prefer this over get_assessment or list_findings, nor does it mention exclusion criteria. It provides some contextual direction through 'approved workspace' but leaves the choice among sibling tools 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 indicate readOnlyHint, idempotentHint, and destructiveHint false. The description adds meaningful behavioral context beyond those annotations: the operation does not contact a target, and it reports the current ownership-authorization state. This helps an agent understand side effects and data scope.

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. It states the action, the resource, the data aspect covered, and a key behavioral qualifier, all without redundancy.

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

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

For a simple read-only list operation with two parameters, one required, and full schema description coverage, the description is complete enough. It names the output domain (assets and ownership-authorization state), and the annotations cover safety and idempotency, so no critical invocation context is missing.

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

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

Schema description coverage is 100%, so the schema already documents workspaceSlug and includeArchived fully. The description does not add parameter-level details, but it also does not need to because the schema carries the burden. Baseline 3 is appropriate.

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

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

The description states a specific verb ('List') and resource ('workspace assets') and adds a distinguishing detail: it reports 'current ownership-authorization state' without contacting a target. This clearly separates it from sibling list tools and from asset-specific operations like get_asset.

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

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

The description gives clear context for when to use the tool: when listing workspace assets and their ownership-authorization state without contacting a target. It does not explicitly name alternatives or exclusions, but the 'without contacting a target' qualifier strongly implies a safe inventory/authorization-check use case.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the 'recent' time scoping, but it does not disclose pagination behavior, ordering, default time windows, or result count limits.

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 front-loads the verb and resource, then lists the optional filters. There is 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?

With no output schema, the description should explain what a successful response contains or at least mention pagination/limits; it does neither. Time filter units are also unexplained. The description is adequate for a basic call with workspaceSlug, but incomplete for full tool understanding.

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 very low at 20%, and the description only names 'actor, action, and time filters' without explaining formats or semantics. In particular, fromAt and toAt are numbers with no stated unit or timestamp convention, so the description does not compensate for the schema's gaps.

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 concrete resource ('workspace audit events'), and names the optional filters (actor, action, time). This clearly distinguishes it from sibling list_* tools like list_assets or list_reports, even without reading the schema.

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: an agent can infer to call this tool when it needs recent workspace audit events. However, it provides no explicit when-not-to-use guidance, no mention of alternatives, and no discussion of prerequisites beyond the required workspaceSlug.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds workspace scoping and optional filter context, but does not disclose behaviors such as pagination, result limits, or whether unfiltered lists return all findings. This is acceptable given the annotations 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 entire description is one concise, front-loaded sentence. It immediately states the action and resource, then appends the optional filter scope without any filler or redundant details.

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

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

For a simple read-only list tool with one required parameter, the description is mostly complete: it names the workspace scope and optional filters. It does not mention pagination, ordering, or explicitly contrast with get_finding, but given the annotations and schema, an agent has enough context to invoke it correctly in most cases.

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

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

Schema description coverage is only 25%, so the description must compensate. It partially does by clarifying that 'status' acts as a lifecycle filter and naming severity as a filter dimension. However, it omits assetId and does not describe possible status values. The parameter names are mostly self-explanatory, but the low coverage means the description only partially bridges the gap.

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'), names the resource ('workspace findings'), and states the optional filtering dimensions ('lifecycle and severity'). This clearly distinguishes it from sibling tools like get_finding and list_assets, making the tool's purpose 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 clearly implies this is the listing tool for findings within a workspace, with optional filters. It does not explicitly call out when to use get_finding instead for a single finding, but the 'List' verb and context make the intended use reasonably clear. No misleading guidance is present.

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

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

Annotations already indicate read-only/idempotent/non-destructive behavior, lowering the burden. The description adds meaningful behavioral detail beyond annotations by disclosing the 'cleared' status constraint and cursor-based pagination semantics, which helps an agent understand traversal expectations.

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

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

The description is a single, tightly packed sentence that front-loads the primary action and resource, then specifies pagination and filters concisely. Every phrase contributes useful information, with no filler or redundancy.

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

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

For a list tool with a fully documented schema and read-only annotations, the description covers scope, pagination, and filters well; an agent can construct a valid request. It does not describe the response shape or explicitly route to sibling search/get tools, but given the simple list semantics and schema completeness, it remains sufficient.

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

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

The input schema covers all four parameters with descriptions, so the baseline is 3. The description's mention of project/status filters and cursor pagination largely mirrors the schema and adds little new meaning. No new parameter semantics such as ordering, defaults, or interactions are provided.

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

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

The description explicitly names the verb (List), the resource (cleared public Hacker Bob CVE records), and includes the core behaviors (cursor pagination and optional project/status filters). It is clearly differentiated from siblings such as get_public_cve_record and search_public_cve_records by the listing action and naming.

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 for paginated enumeration of public CVE records with filters, which is a reasonable usage signal. However, it does not explicitly say when to prefer list_public_cve_records over search_public_cve_records or get_public_cve_record, leaving some routing ambiguity 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful filter context: only non-revoked reports released to the approved workspace are returned. However, it does not disclose pagination, ordering, or response shape, so the added behavioral detail is moderate rather than rich.

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

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

The description is a single compact sentence with no filler. It front-loads the verb and object and uses qualifiers like 'non-revoked' and 'approved workspace' to add meaning without waste.

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

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

For a simple one-parameter, read-only list operation with strong annotations and full schema coverage, the description is sufficient for correct invocation. The absence of an output schema is acceptable because the list operation's intent is clear, and missing pagination details are minor at this complexity level.

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 single parameter workspaceSlug is fully documented in the schema with format, length, and meaning, and schema description coverage is 100%. The description only indirectly references the workspace via 'approved workspace' and adds no new parameter-specific detail, so the baseline of 3 applies.

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

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

The description uses the specific verb 'List' and a clearly bounded resource: non-revoked reports released to the approved workspace. This distinguishes it from sibling tools like get_report (single report) and list_findings (different resource), even without naming alternatives.

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

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

No guidance is given about when to use this tool versus siblings such as get_report or list_findings. The description states only what the tool does, not when to prefer it or what alternatives exist, so usage must be inferred entirely from context.

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

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

The annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond that: only active workspaces are returned, availability is tied to the authenticated account, and the connection remains bound to its approved workspace. This enriches the agent's understanding without contradicting the annotations.

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

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

Two short sentences deliver the core purpose and a key behavioral note with no redundancy. The main action is front-loaded, and every clause adds 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?

For a simple, zero-parameter, read-only listing tool, the description covers what is listed, whose workspaces are visible, the active-only filter, and an important connection-binding detail. The annotations cover the safety profile, so nothing critical is missing for an agent to invoke this tool correctly.

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

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

The tool has zero parameters, so there is no parameter behavior to document. The description is consistent with the empty schema and needs no additional parameter-level explanation.

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

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

The description uses a specific verb and resource: 'List active Hacker Bob workspaces available to the authenticated account.' It clearly scopes the operation to the authenticated user's workspaces and distinguishes it from singular get_workspace and listing tools for other resources.

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

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

The description communicates the context: it lists active workspaces for the authenticated account. It does not explicitly name sibling alternatives or state when not to use it, but the context is clear enough for a zero-parameter listing operation.

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

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

Annotations already indicate idempotency and non-destructiveness, so the description's job is lighter. It adds meaningful behavioral detail beyond annotations: the assessment is immutable, it returns a browser approval URL, and crucially, it never contacts the target. This helps an agent understand side effects and the approval workflow.

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 tight sentences, front-loaded with the core purpose and output, followed by a critical behavioral caveat. No fluff or repetition of schema details.

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 complex tool with seven parameters, a nested coverage object, and no output schema, yet the description only mentions the approval URL. It does not explain what happens after approval, how the assessment relates to launch_assessment, or what the required fields mean. An agent would lack enough context to correctly prepare and complete the workflow.

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

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

Schema description coverage is only 14%, so the description must compensate, but it only vaguely implies assetId via 'verified stored asset.' It does not explain coverage rules, interactionPolicy, depth, boundaries, idempotencyKey, or their relationships. This is a significant gap for an agent trying to construct a valid request.

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 ('Create an immutable assessment'), identifies the resource ('for a verified stored asset'), and names the key output ('browser approval URL'). The final sentence, 'This never contacts the target,' helps distinguish it from execution-oriented siblings like launch_assessment.

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 useful context for when to use the tool: the asset must already be verified and stored, and the tool only prepares an assessment rather than contacting the target. It does not explicitly name alternatives or say 'use launch_assessment instead,' but the behavioral contrast with execution tools 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false; the description adds meaningful behavioral context by stating that no assessment target is contacted, which is a valuable safety guarantee beyond the annotations. It also clarifies the records are 'cleared' public records, adding scope information not present in the schema or annotations.

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

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

The description is a single, well-structured sentence that front-loads the action and resource, then packs the search dimensions and safety constraint into the remainder. Every clause contributes useful information with no wasted words.

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

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

For a read-only search tool with no output schema, the description is nearly complete: it covers the searchable parameters, the publication status filter, and the no-target-contact guarantee. A small gap is that it does not mention paging behavior or default counts, though limit has a default documented in the schema. Overall, an agent can safely and correctly invoke it based on this description plus annotations.

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 query and limit already documented in the input schema. The description largely restates the query semantics (search by CVE identifier, project name, publication status), and the schema already says 'Text to match against CVE identifiers, project names, and publication status.' Thus the description adds limited new meaning beyond the structured 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 begins with a specific verb ('Search') and clearly identifies the resource ('cleared public Hacker Bob CVE records') plus the search dimensions (CVE identifier, open-source project name, publication status). This distinguishes it from sibling tools like get_public_cve_record and list_public_cve_records, which imply fetching or enumerating rather than searching.

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 specifies the searchable fields and the behavioral constraint of 'without contacting any assessment target,' providing clear context for when the tool is appropriate. However, it does not explicitly state when to prefer this tool over the sibling get_public_cve_record or list_public_cve_records, so it stops short of naming alternatives or exclusions.

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