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

With no annotations, the description carries the full burden. It usefully discloses the HTTP verb (GET, implying read-only) and result caps for two actions ('top 100 by vuln count', 'top 50 by count'), which is real behavioral context beyond the schema. It omits auth requirements, pagination, and error behavior.

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

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

Front-loaded purpose sentence followed by a tight action-to-endpoint mapping with inline parenthetical details. No filler text; every line carries information the agent needs.

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 analytics query tool with no output schema, the description covers action selection and rough result scope adequately. It still leaves response shape, authentication, and pagination unaddressed, which the absence of annotations and output schema means the description should ideally cover.

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

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

Schema description coverage is 0% and the single 'action' parameter has no enum, so the schema alone would leave the agent guessing valid values. The description compensates by enumerating exactly the three permitted action strings and what each returns.

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

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

States a specific verb and resource ('Query AttackForge analytics endpoints') and enumerates the three sub-actions with their underlying routes, so the agent knows exactly what capabilities exist. It does not differentiate itself from siblings like reports or vulnerabilities, which also surface aggregate security data.

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 action list implies which query to pick based on the desired aggregate (failed testcases, vulnerable assets, common vulns), giving implicit usage guidance. However, there is no explicit when-to-use-the-tool guidance or exclusions versus siblings such as reports or vulnerabilities.

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 full behavioral burden. The embedded HTTP verbs (GET/POST/PUT) usefully disclose read vs. write semantics, but nothing is said about permissions, error behavior, destructive consequences of update/delete-style actions, or response/pagination behavior.

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

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

A compact, front-loaded action table where every line earns its place — the scope sentence opens, then each action carries its verb, endpoint, and required params with zero filler.

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

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

For a 7-param multiplexer with no annotations and no output schema, the description covers routing and required params but leaves gaps: return shapes for list/get actions, pagination, permission requirements, and the exact schema of 'fields'/'items' are unstated.

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

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

Schema coverage is 0%, so the description does the heavy lifting by mapping each action to its required params (project_id, asset_id, id, items, fields) and clarifying that 'id' means group_id for list_by_group. However the structure of 'fields' and the full item shape are only hinted at ('{asset_name, asset_type,...}').

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

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

States a specific resource ('assets in AttackForge') scoped to project and library, and enumerates all nine actions with their HTTP verbs and endpoints. An agent can tell this is the asset-management surface, distinct from the projects, testcases, or vulnerabilities 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 action list effectively tells the agent which operation to pick and what each requires (e.g. 'list_by_group — requires: id = group_id', 'create_on_project — requires: project_id, items=[...]'), and notes limit defaults to 100. It gives clear context but no explicit when-not or cross-sibling 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?

With no annotations, the description carries the full burden. It does disclose the destructive nature of 'invalidate' and the important default that omitting a key deletes ALL entries, which is genuinely valuable. However, it omits whether the cache is rebuilt automatically, permission requirements, and any rate or concurrency caveats.

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?

Front-loaded purpose sentence followed by a tight action list; every line earns its place with no filler.

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

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

For a two-parameter, no-annotation, no-output-schema tool, the description covers the action space, the key semantics, and even the fields returned by stats (key, age_seconds, ttl_seconds, expired). Only minor gaps remain around permissions and post-invalidation behavior.

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

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

Schema coverage is 0%, yet the description documents both parameters: action accepts stats/invalidate, and key is the optional target for invalidation with an explicit default-to-all behavior. That compensates well for the undocumented schema, though the action values are not formally constrained as enums.

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

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

States a specific verb ('Manage') and resource ('the local SQLite cache for static AF data'), and enumerates the two supported actions with one-line semantics. It is clearly distinguishable from the domain-resource siblings (projects, vulnerabilities, testcases, etc.), though it doesn't explicitly say it is the only cache-management tool among them.

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

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

The action list implies when each mode is used (stats to inspect, invalidate to purge), and the note that omitting key purges everything is useful context. But there is no explicit when-to-use vs alternatives guidance, no statement of prerequisites or when cache invalidation is warranted.

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

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

With no annotations, the description must carry the behavioral burden. It usefully discloses read vs. write intent via HTTP verbs (GET for list/get/notes/workspace, POST/PUT for create/update/clone/archive/restore) and the existence of a restore counterpart implying archive is reversible. It does not mention permissions, side effects on related data, or error behavior.

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

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

The action table is front-loaded, scannable, and each line adds distinct information (endpoint + required params). The repeated 'requires:' token is mildly redundant but keeps the format uniform and predictable.

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 6-parameter, no-annotation, no-output-schema dispatcher, the description covers action routing and required params adequately and even notes the list return envelope (total + has_more). It omits the contents of 'fields', auth requirements, and failure modes, so it is adequate rather than complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does map required parameters per action (id, fields, note_id, note_content) and notes limit defaults to 25, which is real added meaning. However, it never explains the shape or contents of the free-form 'fields' object used by create/update, leaving the most ambiguous parameter undocumented.

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 tool names the resource (AttackForge projects) and enumerates twelve concrete actions with their HTTP endpoints, so an agent can see exactly what operations exist. It distinguishes itself from siblings like vulnerabilities/assets by resource, though the umbrella verb 'Manage' alone would be vague without the action table.

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 list entry explicitly routes the agent: 'Returns total + has_more. Use projects.get for full detail,' which clarifies list vs. get. No guidance is given on when to prefer this tool over the sibling raw_request for other endpoints, but for a project-scoped CRUD surface the context is clear.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it does not disclose authentication/permission requirements, rate limits, error response behavior, or that POST/PUT/DELETE methods cause mutations. For a tool capable of arbitrary destructive calls, this 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?

Short and front-loaded, with the core purpose in the first sentence and parameter semantics in a compact args block. No filler sentences.

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 annotations, no output schema, and 0% schema coverage, the description only covers argument meaning. It omits the behavioral context (auth, side effects, return/error shape) that an agent needs to invoke an arbitrary-endpoint tool safely, so it is incomplete 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?

Schema description coverage is 0%, so the description must compensate, and it does: it enumerates allowed HTTP methods and gives concrete endpoint examples and the intended meaning of params and body. It stops short of specifying body/params encoding details per method, but adds real meaning beyond the bare schema.

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

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

States a specific verb and resource: make a raw HTTP request to an AttackForge SSAPI endpoint. It is clear this is a generic/escape-hatch tool, but the description never contrasts it with the domain-specific siblings (vulnerabilities, projects, etc.), leaving the agent to infer that this is the fallback when no wrapper exists.

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 when-to-use guidance, no statement of when this is preferable to the dedicated sibling tools, and no exclusions or prerequisites. An agent has to guess that raw_request is the last resort rather than the default.

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 disclosure burden. The POST/PUT endpoints imply write operations, but nothing is said about authentication needs, permissions, whether updates are destructive/overwriting, error behavior, or what is returned — significant gaps for a 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?

Front-loads the tool's purpose in one sentence, then uses a clean per-action breakdown mapping action name to endpoint and required inputs. Slightly verbose indentation but no wasted prose.

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 4-parameter tool with no output schema or annotations, the description covers action routing and required fields adequately, but omits when to choose each action, authentication/permission expectations, and any notion of results — leaving the agent with gaps 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?

With 0% schema description coverage, the description compensates well: it names vulnerability_id, note_id, and fields per action, and spells out key fields for create_note (projectId and note required; note_type values 'PLAINTEXT'/'RICHTEXT'). Only the accepted values of the free-form `action` string and the full updatable field set are left implicit.

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

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

States a specific verb+resource ('Manage remediation notes on AttackForge vulnerabilities') and enumerates exactly two operations with their REST endpoints. An agent can tell this handles remediation notes rather than the broader sibling categories (vulnerabilities, projects), though it doesn't explicitly position itself against those 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?

Enumerating the two actions (create_note, update_note) with their required parameters implies when each applies, but there is no explicit when-to-use/when-not guidance or routing to alternatives such as a generic raw_request sibling. Usage must be inferred from the required-parameter annotations.

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 disclosure burden. It reveals the underlying endpoints and that get_data is a POST that generates (mutating/possibly long-running) while get_report is a GET read, which is genuinely useful. It does not mention auth requirements, whether generation is synchronous, or what the response contains.

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 action list is front-loaded and formatted as a compact per-action breakdown, with zero filler sentences. The endpoint strings are slightly redundant with the schema, but they earn their place by clarifying the action semantics.

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 annotations, no output schema, and 0% schema description coverage, the description covers the essentials for invocation (actions, required params, examples) but leaves gaps: the structure of `options`, whether reports are generated asynchronously, and what is returned by each action are all unstated.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: it enumerates the two valid action values and which parameters each requires (project_id, report_type, optional options for get_data; project_id, report_type for get_report), plus report_type examples. The content and shape of the optional `options` object remains undefined.

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 concrete verb and resource ("Generate and retrieve AttackForge project reports") and splits it into two clearly labeled actions, get_data (POST) and get_report (GET), so the agent knows exactly what the tool does. It does not differentiate from sibling resource tools like projects or vulnerabilities, but the action-level distinction is solid.

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?

Listing the HTTP method per action implies the generate-vs-retrieve split, and required parameters are stated per action, which is useful routing information. However, it never explicitly says when to choose get_data over get_report, nor any prerequisites such as permissions or whether a report must exist first.

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 behavioral burden. It does add real value beyond structured fields by disclosing that list returns total + has_more and defaults limit to 50. It is silent, however, on whether assign/update/add_note are idempotent, what permissions they require, or what side effects they have, leaving mutation behavior opaque.

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

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

Purpose is front-loaded in one sentence, followed by a compact action table with endpoints and required params aligned for scanning. Every line carries actionable information with no filler.

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

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

For a six-parameter, five-action tool with no output schema and no annotations, the description is adequate on action routing and required params but thin on return values for mutations, error behavior, and the shape of the free-form fields object. It covers enough to invoke the tool but not enough to use it confidently across all actions.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it maps project_id, testcase_id, note, fields, and limit to the actions that use them and notes the limit default and key fields (status, linked_vulnerabilities). It stops short of describing the fields object structure or allowed keys in full.

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

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

The description states a specific verb+resource ('Manage test cases assigned to AttackForge projects') and then enumerates five distinct actions with their HTTP endpoints, which cleanly separates this tool from siblings like testsuites and vulnerabilities. An agent can tell immediately that this operates on test cases within a project 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?

Each action lists its required parameters (project_id, testcase_id, note, fields), which implies when each is applicable, so an agent can infer the correct action for a given intent. However, there is no explicit guidance on selecting this tool over siblings such as testsuites or remediation, and no exclusions.

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

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

No annotations are provided, so the description carries the full burden. It lists HTTP methods but does not disclose mutation effects, permissions/auth needs, reversibility, or pagination. For a tool containing multiple write actions (create, update, add_testcase), this 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?

Well-structured action list with one line per action and inline parameter requirements. Front-loaded with the resource. Efficient, though the parenthetical 'requires' notes are terse enough to be borderline cryptic.

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/parameter mapping that the bare schema lacks, which is the tool's main need. But with no annotations, no output schema, and 0% schema coverage on a 5-param multi-action tool, it omits auth, permissions, response shapes, and field/item structure.

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

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

Schema description coverage is 0%, so the schema names params but documents nothing. The description compensates partially by mapping required params per action (id, testcase_id, fields, items), which is genuinely useful. However, it does not explain the shape of 'fields' or 'items' objects, leaving nested structure undefined.

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?

Clear verb+resource: 'Manage AttackForge testsuite libraries'. The action list enumerates exactly what operations are available and distinguishes this tool from siblings like testcases and projects. It is not quite a 5 because 'manage' is a broad umbrella rather than a single precise operation.

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 action list implies when to use each action, but there is no guidance on when to choose this tool over siblings (e.g. testcases vs testsuites) or prerequisites beyond required params. Usage is only implied by the action 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?

With no annotations, the description carries the full burden. It discloses the HTTP verbs and endpoints (POST /utils/markdown-to-richtext, GET /config/form/:config_type) and required parameters, which is useful context, but it says nothing about auth needs, whether the POST conversion is side-effect-free, error behavior, or return 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 front-loaded with the action list and scannable per-action (endpoint, required params, behavior). The endpoint paths are somewhat redundant for an agent but earn their place as routing detail; there is no 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?

No output schema and no annotations mean the description should carry more: it covers what each action takes but not what it returns or how errors surface. For a two-action utility tool it is adequate, but the return-value contract for markdown_to_richtext is left undefined.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it names both action values, states which parameter each action requires, and gives example config_type values ('vulnerability', 'project'). It adds no format or type detail for the markdown parameter, keeping it just short of a 5.

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 tool name 'utils' is a category, not a purpose, but the action list gives specific verbs and resources for each action ('Convert markdown to AF rich text format', 'get_form_config' with its endpoint). An agent can tell what each action does without opening the schema. It does not explicitly differentiate itself from the domain siblings, though the grab-bag utility scope is implicit.

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?

'Use before setting description/recommendation/note fields' gives explicit when-to-use guidance for markdown_to_richtext. get_form_config has no usage guidance beyond its required parameter, and there is no when-not or alternative-selection advice for either action.

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

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

With no annotations, the description carries the full burden and does disclose useful traits: list returns summary-only plus total/has_more, get returns full detail, and global list can return 500+ items. It omits permission/auth requirements and the destructive/irreversible nature of create/update/bulk_create.

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?

Long but well-structured as an action/requirements table with front-loaded action names; nearly every line adds routing or field-requirement value. Minor redundancy in the two 'Key fields' blocks, which repeat tags/notes/custom_fields shapes.

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 10-action multiplexed tool with no annotations and no output schema, the description covers action routing, required inputs, and return shape hints sufficiently to invoke correctly. It would be stronger with auth/error and mutation-impact notes, but nothing essential 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 0%, and the description compensates by listing required fields per action and flagging the camelCase projectId (create) vs snake_case project_id (update) discrepancy, which is not derivable from the schema. Remaining params like limit, tags, and items structure get only partial treatment.

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?

It states the resource (AttackForge vulnerabilities) and enumerates ten concrete actions with their HTTP verb/path, so an agent can map intent to action without guessing. Sibling tools (projects, testcases, assets) are clearly not overlapping.

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?

Explicit routing guidance per action: prefer project_id scope to avoid 500+ item global lists, use get for full text fields, and summarize_custom_fields should be used first to discover custom field keys before list_by_custom_field. When-to-use and sequencing are spelled out rather than implied.

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