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

Annotations already establish readOnly, idempotent, non-destructive, open-world behavior, so the bar is lower. The description adds that generation is bounded, must use explicitly supplied IDs, and returns base64 file content suitable for saving. It does not cover auth requirements or output size 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?

Three sentences, front-loaded with purpose, then return payload, then exclusions. No filler, and the ordering puts the key constraint where an agent will read it first.

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 an output schema present, return values need not be explained, and annotations cover safety. The description handles purpose, bounds, and exclusions well, but leaves material gaps: label_name's meaning and asset_ids_json's format are undocumented anywhere, which matters 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 0% for two parameters, so the description must carry the burden. It hints that asset IDs are explicitly supplied and bounded, but never clarifies the JSON-string format of asset_ids_json, and label_name is not mentioned at all. Half the parameters remain semantically unexplained.

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 ('Generate'), resource ('printable Snipe-IT asset-label PDF'), and scope ('for explicitly supplied asset IDs'). It is immediately distinguishable from lookup-oriented siblings like assets_search and catalog_search.

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 gives an explicit when-not clause: 'Do not use for ordinary asset lookup or for unbounded label generation.' That clearly routes the agent away from misuse. It stops short of naming the specific alternative tool for lookup or unbounded generation.

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 cover read-only, idempotent, open-world, and non-destructive behavior. The description adds genuine non-structured context: product keys are returned only when both Snipe-IT and the caller's permissions expose them. The trailing 'This tool is read-only' sentence partly restates readOnlyHint=true, keeping it short of a 5.

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?

Three short sentences with the primary action front-loaded and no filler. The final read-only sentence is largely redundant with the annotations, so it does not fully earn 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?

An output schema exists, so return-shape explanation is not required, and the permission caveat is a useful addition. However, for a zero-required-parameter tool with 0% schema coverage, the description never clarifies identifier selection rules or pagination, leaving a real gap.

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

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

Schema description coverage is 0% across 5 parameters, so the description must carry the load. It mentions 'exact asset tag or serial', which touches two parameters, but asset_id, limit, and offset are never explained, nor is it stated that at least one identifier must be supplied. Compensation is partial at best.

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 ('Read software licences') scoped to 'one asset', which is clearer than a bare resource name. It does not explicitly contrast with licenses_search, licenses_write, or license_seats, so sibling differentiation is left to inference.

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

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

The 'when needed' phrasing around asset tag/serial resolution hints at how to identify the target asset, but there is no explicit when-to-use guidance and no named alternative (e.g. licenses_search for licenses not tied to an asset). An agent must infer the boundary from the name alone.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true. The description adds meaningful context beyond these: it never deletes an asset, it resolves IDs deterministically, and email/identifiers must be unambiguous. It does not describe what each action does to asset state or any permission/rate requirements.

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

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

Three tight sentences, front-loaded with the core actions and scope, followed by input constraints and the deletion disclaimer. 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?

An output schema exists so return values need not be explained, and the safety profile is covered by annotations. However, for an 11-parameter mutation tool with 0% schema coverage, the description leaves most parameter semantics and per-action behavior undocumented, which is a notable gap.

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

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

Schema description coverage is 0% across 11 parameters, so the description carries the full burden and only partially compensates. It hints at action_name via the verb list and references identifiers and exact user email, but says nothing about expected_checkin, next_audit_date, location_id, assigned_to_id, checkout_to_type, note, or serial vs asset_tag vs asset_id.

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 specific verbs (checkout, checkin, audit, restore) and a specific resource (one Snipe-IT asset), and explicitly scopes out deletion, which distinguishes it from delete_resource. It stops short of naming how it differs from nearby siblings like asset_maintenance or inventory_lifecycle, so it is clear but not fully differentiated.

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 gives an explicit gating condition ('Use only when the user explicitly requests the lifecycle action') and states the identifier-resolution requirement. It does not name alternative sibling tools or when-not-to-use cases beyond the explicit-request rule, so it falls short of a full 5.

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

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

Annotations already disclose non-readonly, non-idempotent, non-destructive, open-world behavior. The description adds no further behavioral detail: it does not state whether update/complete are reversible, what happens to omitted fields, whether partial updates are supported, or what the output contains. With annotations carrying meaningful safety signals, the description should add extra context but does not.

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: the first lists supported actions, the second scopes the tool and points to deletion. No filler, front-loaded with the capability summary, and easy to parse quickly.

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 handles many actions with 12 parameters, one required, and no schema descriptions, making guidance critical. Despite having an output schema (which reduces the need to explain returns), the description does not clarify how parameters map to actions, what requiredness looks like per action, or typical workflows. It is inadequate for a multi-action tool with zero parameter documentation.

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 12 parameters (including action_name, maintenance_id, asset_id, dates, cost, notes, and maintenance_type_id) have no documented meaning anywhere. The description does not explain any parameter usage, requiredness, dependencies, or how they map to the various actions. It leaves the agent guessing how to populate the schema for each action.

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 enumerates specific actions (list, retrieve, create, update, complete, add/list notes) and clearly scopes the tool to Snipe-IT asset maintenance records and types. It is explicit about what the tool cannot do (delete) and names the sibling that handles deletion. It loses a point only because it packs multiple distinct operations into one tool, which can blur the primary purpose at a glance.

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 explicit when-to-use ('Use for maintenance records only'), a clear exclusion ('cannot delete maintenance records or types'), and points to the alternative tool ('delete_resource'). An agent can immediately decide whether this tool is appropriate or should route to delete_resource.

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 write (readOnlyHint=false), non-destructive, non-idempotent, and open-world behavior. The description adds real context beyond that: the operation is limited to the authenticated user's own request and requires explicit user intent, plus the negative capability list. It does not say what happens on a duplicate submit/cancel or whether permission scopes are required, so it is not a 5.

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?

Three short sentences, front-loaded with the core action, then the trigger condition, then the exclusions. No filler and nothing repeated from structured fields.

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?

An output schema exists, so return values need not be described. However, for a 6-parameter tool with 0% schema coverage, the description leaves the most consequential ambiguity unresolved: which identifier to supply and what action_name accepts.

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% across 6 parameters, so the description must carry the load. It only hints at action_name's two modes (submit/cancel) without giving literal values, and says nothing about asset_id vs asset_tag vs serial vs expected_checkout vs note, leaving the agent unable to choose the identifying 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?

States a specific verb pair (submit/cancel) on a specific resource (a requestable asset request), scoped to the authenticated user's own request. It also explicitly distinguishes itself from adjacent operations (approval, checkout, deletion), so an agent can separate it from assets_write, asset_lifecycle, or delete_resource.

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 only when the user explicitly asks to request or cancel a request" is an explicit trigger condition, and "does not approve requests, checkout assets, or delete data" is an explicit when-not boundary. It stops short of naming the sibling tool to use for approval/checkout instead, which keeps it out of the top band.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description's only addition is an enumeration of returned fields (asset_tag, serial, model_name, custom_fields, etc.), which largely duplicates the output schema, and it says nothing about auth requirements, result caps, or pagination behavior despite page/limit/offset/per_page parameters existing. Minimum-viable-plus given the low bar set by 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?

Four sentences, front-loaded with the purpose and followed by usage scope, with no filler or repetition. The return-field enumeration is the one weak spot: it is long and partially redundant with the output schema, spending space that parameter guidance would have used better.

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?

An output schema exists so return values need not be re-explained, yet the description spends its words there while leaving the 23-parameter surface effectively undocumented, including the required action_name. For a tool this wide (openWorld, 23 params, 0% schema coverage), the description is not complete enough 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 23 parameters at 0% schema description coverage, the description carries the full documentation burden, but it explains only the conceptual lookup modes and omits any parameter names or semantics. Critically, the sole required parameter, action_name, is never mentioned, nor are filter_operator, custom_field_operator, advanced_filter_json, or the six pagination/sorting parameters. An agent cannot reliably construct a correct call from this text.

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 and resource ("Search and retrieve Snipe-IT hardware") and then enumerates the lookup modes: ID, exact asset tag, exact serial, text, structured fields, custom fields, and the requestable catalog. It also distinguishes itself from the write, lifecycle, and delete siblings with an explicit exclusion, so an agent can place it correctly without opening a 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?

"Use for every read-only asset question" gives the positive trigger, and "Do not use for writes, lifecycle actions, or deletion" names the exclusion conditions that route the agent to assets_write, asset_lifecycle, or delete_resource. This is explicit when/when-not guidance rather than inferred 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?

Annotations already declare readOnly=false, destructive=false and idempotent=true, so the safety profile is covered; the description still earns credit by scoping the write surface explicitly and noting the return is conditional on the backend including the asset. It does not, however, explain the create-vs-update discriminator that underlies the idempotent claim.

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?

Three sentences, all load-bearing: purpose first, usage gate second, exclusions and return semantics last. No filler or restatement of the 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?

An output schema exists, so return-value detail is not required, and the exclusion list covers a lot of ground for a busy write tool. But with 18 undescribed parameters, an unexplained required action_name, and no statement of what identifies the target asset on update, the definition leaves the agent guessing at the exact call shape.

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% across 18 parameters, so the description carries the full semantic burden and mostly fails to. It gestures at "explicit common fields and optional custom fields" (presumably custom_fields_json), but never names a field, gives the custom_fields_json format, or explains the required action_name discriminator that selects create vs update.

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 pair (create/update) and a specific resource (Snipe-IT hardware asset), and explicitly enumerates what it is NOT (delete, checkout, checkin, audit, restore). That enumeration cleanly separates it from siblings such as asset_lifecycle, delete_resource, and asset_maintenance without opening any 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?

"Use only for an explicit create or update request" is a clear gating condition, and the negative list tells the agent when to look elsewhere. It stops short of naming the sibling to use for the excluded operations (e.g., asset_lifecycle for checkout/checkin), so routing is implied rather than explicit.

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, openWorldHint and destructiveHint=false, so the 'read-only' sentence largely restates structured data. The one genuinely additive detail is that relationship actions 'return rich records without hiding model information,' which hints at output behavior 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?

Three sentences, front-loaded with the verb and resource list, with no padding in the enumeration. The final 'This tool is read-only' sentence is largely redundant against the annotations, a minor 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?

With an output schema present, return values needn't be explained, and annotations cover the safety profile. However, for a 9-parameter tool at 0% schema coverage, the description omits the meaning of most parameters, leaving the definition incomplete 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 0% across 9 parameters, so the description must carry the load. It does enumerate plausible catalog_type and action_name values, but sort, limit, order, query, offset, item_id, and category_type are entirely undocumented, leaving most parameter semantics unexplained.

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 ('Read') plus an enumerated set of Snipe-IT catalog resource types, so the agent can identify the tool's domain. The closing 'This tool is read-only' implicitly distinguishes it from the catalog_write sibling, but it never names that sibling, so differentiation is only partial.

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. The mention of relationship actions (assets_by_model, assets_by_status, etc.) reads as parameter values rather than as routing advice, and no alternative tool is named, leaving the agent to infer 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?

Annotations already declare the safety profile (not read-only, not destructive, idempotent, open-world). The description adds one useful behavioral fact beyond them: there is no delete action and deletions live in delete_resource. However, it doesn't clarify how create vs update is disambiguated or what action_name controls, so it only modestly enriches the annotation picture.

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?

Three sentences, front-loaded with the core purpose, followed by usage context and the deletion exclusion. No wasted prose, though the field enumeration is somewhat list-like rather than informative.

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

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

An output schema exists so return values needn't be explained, and annotations cover the safety profile. But for a 26-parameter tool with 0% parameter coverage, the description leaves significant gaps around what catalog_type values exist and how action_name selects the operation, making it only minimally complete given the 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?

With 26 parameters at 0% schema description coverage, the description carries the full documentation burden but only gestures at broad field categories. It never explains the two required parameters (catalog_type, action_name), which are the most critical for invocation, nor the integer IDs (parent_id, manager_id, depreciation_id, etc.). This leaves most parameter semantics undocumented in both schema and 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 gives a specific verb pair (create/update) and resource (Snipe-IT catalog records) and enumerates the field domains covered (model, status, hierarchy, contact, depreciation, type). It also distinguishes itself from delete_resource, so an agent can route writes vs deletes correctly. It stops short of naming the search sibling, but the scope 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?

"Use for normal requested configuration writes" tells the agent the operational context, and the explicit routing of all deletions to delete_resource acts as a strong when-not-to-use exclusion. It lacks guidance on how it relates to catalog_search or other write siblings, so it is not fully exhaustive.

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 trailing 'read-only' is largely redundant. The description does add real context beyond annotations by explaining that dynamic values surface via stable named properties and extra_fields arrays, but it discloses nothing about auth scope, result limits, or 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?

Compact and front-loaded: the resource scope leads, then the resource_type instruction, then the output-shape note. The one wasted sentence is the closing 'This tool is read-only', which repeats the annotation and the opening verb.

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?

An output schema exists, so return values need not be described. However, for a 7-parameter search with 0% schema coverage, key filters like action_name, item_id, and query are left completely unexplained, so the definition is only partially 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 0% across 7 parameters, so the description carries the full burden and mostly fails. It only addresses resource_type, and notably leaves action_name (default 'list') and fieldset_id undefined, which are central to how the search is scoped.

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 (read/search) and resource (custom fields, fieldsets, db_column identifiers, validation metadata, fieldset membership), and the final clause 'read-only' cleanly distinguishes it from the custom_fields_write sibling. An agent can tell what it returns without opening 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?

It gives one operational hint ('Use resource_type=field or fieldset'), which is genuinely useful for selecting the resource class. But it offers no when-to-use guidance relative to the many sibling search tools (catalog_search, inventory_search, etc.) and no exclusions or prerequisites.

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 destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds a genuinely useful constraint (no deletion), but with 13 parameters it says nothing about what each action mutates, what is required per action, or auth/permission needs.

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?

Three short sentences, front-loaded with the capability list followed by the action vocabulary and the exclusion. 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?

The output schema exists, so return values need not be described, and the description does cover purpose and the action vocabulary. However, for a 13-parameter multi-action tool with zero schema documentation, the absence of any parameter-to-action mapping is a real completeness gap.

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

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

Schema description coverage is 0%, so the schema supplies only parameter names and defaults. The description usefully fills the one critical gap by naming the valid action_name values (the schema has no enum), but it leaves the other twelve parameters (field_id, fieldset_id, element, field_format, field_order_json, etc.) with no explanation of which action consumes them.

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 (create/update/associate/reorder fields and fieldsets) and enumerates the seven supported operations by name. It also explicitly excludes deletion, which cleanly separates it from custom_fields_search and delete_resource 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?

It tells the agent to drive the tool via explicit action_name values and states a clear negative boundary ('cannot delete fields or fieldsets'), which implicitly routes deletion elsewhere. It stops short of naming the alternative tool or explaining when to pick a specific action over another.

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 destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is largely covered. The description adds genuine value beyond that: permanence of the deletion, the mandatory confirm-with-user precondition, and the parameter routing per target type. It does not disclose permission requirements or whether deletion cascades to related records.

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?

Three sentences, front-loaded with the destructive scope and the exclusivity claim, followed by the precondition and the parameter routing. Every sentence carries information an agent needs; 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 destructive mutation with full annotation coverage and an existing output schema, the description is nearly complete: it covers destruction semantics, the confirmation workflow, and argument selection. The remaining gap is the undefined resource_type vocabulary, which matters because that parameter is required.

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 clarify the file path (parent_id + file_id) versus the record path (resource_id), but the required resource_type parameter is never explained — no accepted values or what entities it covers — so half the semantic burden is still unmet.

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 ('remove confirmed Snipe-IT data') with the scope modifier 'Permanently or destructively'. It also distinguishes itself from all siblings by declaring it is 'the only MCP tool that can issue HTTP DELETE', so an agent can route to it without opening other schemas.

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?

Gives an explicit when-to-use gate ('only for an explicit deletion request after the calling agent has retrieved and shown the exact target and received immediate user confirmation') and branches the usage by target type (files vs records). Nothing about selection is left to inference.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: base64 is returned only when the file fits max_inline_bytes, otherwise metadata with content_truncated=true, plus the explicit no-write boundary. Auth/rate-limit details are absent.

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?

Three tight sentences, front-loaded with the two modes and the truncation rule, with zero filler. Each sentence adds a distinct constraint (mode, size behavior, write exclusion).

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?

An output schema exists, so return values need not be explained, and annotations cover safety. However, with 7 parameters at 0% schema coverage, the description omits the action_name vocabulary and valid parent_type values, leaving an agent unable to construct a correct call from either field alone.

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% across 7 parameters, so the description must carry the load. It explains max_inline_bytes semantics well but leaves action_name (no enum values), parent_type, parent_id, file_id, limit and offset entirely undocumented, so most parameters remain opaque.

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 two specific modes (list attachment metadata, download one bounded attachment) for a named resource and system (Snipe-IT attachments), and explicitly bounds itself against siblings by saying it 'cannot upload or delete files', separating it from files_upload and delete_resource.

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 makes clear when each mode applies (list metadata vs. a single bounded download) and gives a negative boundary ('cannot upload or delete files'), which routes the agent away from write siblings. It stops short of naming the concrete alternatives or listing the action_name values that select each mode.

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?

Goes beyond the annotations by disclosing that the filename is sanitized, upload size is bounded, and multipart encoding is used, plus the read/delete limitation. It does not state auth requirements, the actual size ceiling, or the non-idempotent consequence of repeat uploads, so it is strong but not exhaustive.

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?

Three short sentences, front-loaded with the action and scope, then constraints, then non-capabilities. Every clause carries information; nothing is redundant.

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?

An output schema exists so return values need no explanation, and the write/safety profile is reasonably covered. However, for a 6-parameter tool with zero schema coverage and no enum hints, the description leaves the agent unable to determine valid parent_type values or payload size limits.

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 there are 6 parameters, so the description must carry the load. It only loosely gestures at filename and base64 content and never explains parent_type's accepted values, parent_id semantics, mime_type defaults, or the notes field, leaving most parameters undocumented in both places.

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 ('Upload one explicitly supplied base64 attachment') scoped to 'a supported Snipe-IT parent'. It also separates itself from the sibling files_read by declaring 'This tool cannot read or delete attachments', so an agent can route without opening a 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 'one explicitly supplied base64 attachment' phrasing tells the agent this is for an already-obtained payload rather than fetching content, and the read/delete exclusion implicitly routes those needs to files_read. It stops short of naming the alternative tool or stating prerequisites (permissions, valid parent types).

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

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

Annotations declare destructiveHint=true and non-idempotent, and the description usefully narrows that: upload never processes a file, process only fires on an explicit request, and the tool cannot delete import files. It also implies a confirmation gate before deletion. It stops short of describing auth requirements, side effects of configure/validate, or backup 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?

Three sentences, zero filler, and the purpose is front-loaded before the two safety constraints. Each sentence carries distinct information and nothing is repeated from the annotations or schema.

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

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

An output schema exists, so return values need no explanation, and the stage enumeration plus safety caveats cover the behavioral core of a multi-action tool. The gap is that an agent cannot tell which parameters belong to which stage (e.g. whether content_base64 is for upload and field_map_json for configure), which is essential for a 9-parameter action-dispatch tool.

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% across 9 parameters. The description effectively supplies the value set for the required action_name (the six stages), which the schema leaves as an unconstrained string, but it says nothing about filename, import_id, content_base64, field_map_json, run_backup, limit, or offset, so most parameters remain undocumented in both places.

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 (run) and resource (the Snipe-IT CSV import workflow) and enumerates the six stages the tool drives (list, get, upload, configure, validate, process). This lets an agent identify the tool without opening the schema, and the deletion clause distinguishes it from delete_resource.

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?

Gives an explicit trigger condition for the riskiest stage ('process runs only when action_name=process is explicitly requested') and routes deletion to delete_resource 'after separate confirmation'. However it does not say when to use list vs get vs configure vs validate, leaving the ordering of stages to inference.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false; the description's 'never deletes records' largely restates destructiveHint=false rather than adding new behavior. It says nothing about the non-idempotent nature of repeated checkouts or any permission requirements, so it adds only modest value beyond the structured hints.

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?

Three tight sentences, no filler, with the core capability front-loaded and per-type constraints following. Every clause conveys actionable information.

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

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

An output schema exists so return values need no explanation, but this is a non-read-only, 7-parameter, 0%-documented mutation tool and the description covers only target-type rules. Missing action_name/quantity semantics and idempotency behavior leave meaningful 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?

Schema description coverage is 0% across 7 parameters, so the description must carry the load; it clarifies what checkout_to_type/assigned_to_id must be per inventory_type, which is genuinely useful. However, action_name, item_id, quantity and note are never explained, leaving half the surface 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?

States specific verbs (checkout/check in) and resources (accessories, components, consumables), and scopes itself to official Snipe-IT assignment workflows. It implicitly separates itself from record-creation tools, but never names a sibling such as inventory_write or asset_lifecycle, so the boundary is inferred rather than explicit.

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?

Gives real selection context by stating the valid target for each type: accessories accept user/asset/location, components require an asset, consumables require a user. That tells the agent how to pick arguments per case, but it offers no when-to-use/when-not guidance against the adjacent inventory_write or asset_lifecycle tools.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds only that returned fields are 'normalized' and 'audit-safe', which is vague phrasing rather than concrete behavioral context (no pagination, no result-count, no permission notes). Nothing contradicts 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?

Three tight sentences, action verb and scope front-loaded, and the exclusion clause placed last where it belongs. The long comma-separated field inventory is a mild dump but is the substantive part of the description.

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?

An output schema exists, so return-value explanation is correctly omitted, and the required parameter's allowed values are stated. However, for a 13-parameter search tool with zero schema documentation, the description leaves the bulk of the input contract (filtering, paging, action_name) unexplained, so it is only minimally 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% across 13 parameters, so the description carries the full explanatory burden, yet it only clarifies the one required parameter (inventory_type: accessory/component/consumable). It says nothing about query, limit/offset paging, sort/order, action_name (default 'list'), or the item_id/company_id/category_id/location_id/supplier_id/manufacturer_id filter semantics.

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

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

The description opens with a specific verb ('Read') and resource scope (accessories, components, consumables) and enumerates the field families returned, so the agent knows exactly what is being fetched. It does not explicitly name its search siblings (catalog_search, assets_search) to distinguish the domain, which keeps it just below a 5.

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

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

Explicit negative routing is present: 'Do not use for writes, assignments, or deletion,' which steers the agent away from inventory_write / inventory_lifecycle / delete_resource without naming them. It also tells the agent to set inventory_type, giving a positive usage condition. It stops short of naming the alternative search tools for adjacent domains.

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

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

Annotations declare the safety profile (readOnly=false, idempotent=true, destructive=false, openWorld=true), and the description adds the capability boundary by listing the operations it deliberately omits. It does not disclose auth requirements, what an update overwrites, or error behavior, so it adds real value but not exhaustive behavioral detail.

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

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

Three tight sentences, no redundancy; the core purpose and the capability boundary are front-loaded so the agent gets the essential routing information immediately.

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?

An output schema exists so return values need not be explained, but for a 17-parameter write tool with 0% schema coverage the definition leaves parameter usage almost entirely undocumented. Given the tool's complexity, a description this thin is materially incomplete.

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% across 17 parameters and the description contributes no parameter-level meaning beyond the phrase "explicit fields" and a vague "required IDs are known." With zero schema documentation and 17 params, the description fails to compensate, and the "required IDs" phrasing even misleads since only inventory_type and action_name are required while the rest carry defaults.

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 pair (create or update) and a specific resource (one accessory, component, or consumable), and explicitly names the write actions it does NOT perform (assign, check in, check out, delete), which cleanly separates it from siblings like inventory_lifecycle and delete_resource.

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 for ordinary inventory record writes after required IDs are known" gives clear context, and the closing sentence enumerates the excluded operations, implying the alternative tools. It stops short of naming those alternatives or stating prerequisites/permission needs explicitly, so it is strong but not fully prescriptive.

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 destructiveHint=true, readOnlyHint=false, and non-idempotent, so the safety profile is covered. The description adds value by attributing destructiveness to the sync action specifically and warning that it materially changes users, but it does not mention permission requirements, rate limits, or scope of the sync.

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?

Three sentences, front-loaded with the two capabilities, followed by the critical safety constraint. No filler and every sentence carries distinct information.

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

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

An output schema exists, so return values need no prose. For a single-parameter tool with destructive capability, the description covers capability, value semantics, and the guardrail against unintended sync — nothing an agent needs to call it safely is missing.

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

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

Schema coverage is 0% (a bare required string with no enum), so the description carries the full burden and does so: it enumerates the accepted values (test, sync) and explains the semantics and consequence of each. There is no ambiguity about what values are legal.

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 two concrete operations on a specific resource: testing the Snipe-IT LDAP connection and synchronizing LDAP users. It names the two action values and their distinct effects, so an agent can tell this apart from generic user-write siblings without opening 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?

It gives explicit when-to-use guidance per action (test = connectivity check only; sync = only when synchronization was explicitly requested) and an explicit prohibition (never infer sync from a test request). The routing logic between the two modes is fully spelled out.

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 idempotent=true, destructiveHint=false, and readOnlyHint=false, so safety is covered. The description adds non-obvious behavior: checkout's one-target cardinality and the fact that checkin removes an assignment without deleting the licence or seat. It stops short of covering the non-seat parameters.

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?

Three short sentences with the action list front-loaded and the destructive-behavior caveat immediately after. No padding, though the structure is dense enough that the mutation caveat could be easier to scan.

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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. Still, for a mutating multi-action tool with seven undocumented parameters and no enum on the required action_name, the description leaves an agent guessing about pagination and note/ID semantics.

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% with 8 parameters, so the description must carry the load. It usefully documents the valid action_name values and the assigned_user_id/assigned_asset_id exclusivity, but says nothing about limit, offset, seat_id, license_id, or note.

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?

Names specific verbs (list, checkout, checkin, update) against a specific resource (licence seats), and the seat-level scope distinguishes it conceptually from licences_search and licenses_write. It never names a sibling explicitly, so it falls short of full 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?

"Use mutation actions only for explicit assignment requests" is a genuine when-to-use condition, and "checkout accepts exactly one user or asset target" scopes the mutation path. It gives clear context but does not point to alternative siblings (e.g. licenses_search) for read access.

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 non-destructive, so restating 'read-only' adds nothing. However, 'Product keys appear only when permissions allow' is a genuine behavioral disclosure about permission-gated field redaction that annotations cannot express, and it is exactly the kind of context an agent needs before reporting results.

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?

Three sentences, front-loaded with the verbs and resource, then the field inventory, then the permission caveat. No filler or repetition; it could be slightly tighter but nothing is wasted.

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

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

An output schema exists, so return-value documentation is unnecessary. Still, a 12-parameter tool with 0% schema coverage and no explanation of action_name, query, or pagination leaves real gaps the description does not close, making this only minimally viable.

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% across 12 parameters, so the description carries the full burden. It lists domain concepts (category, manufacturer, supplier, company, maintenance) that map loosely to some *_id params, but omits sort/limit/order/query/offset/action_name/license_id entirely and never explains the action_name mode switch or pagination defaults.

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 specific verbs and resource ('List, search, or retrieve software licences') and enumerates the domain fields it operates on, so the agent knows exactly what domain this covers. It does not name or differentiate itself from siblings like licenses_write, license_seats, or assets_search, which keeps it short of a 5.

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

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

There is no guidance on when to use this tool versus license_seats or the write counterpart, and no indication of what the 'action_name' parameter (default 'list') actually selects between the advertised list/search/retrieve modes. The agent must guess how to trigger search vs retrieval.

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 this is a non-readonly, non-destructive, idempotent, open-world write. The description adds real context beyond them: the deliberate translation of public product_key into Snipe-IT's write-side serial field, and an explicit statement that deletion and seat assignment are out of scope. It still doesn't say what happens on update versus create or what permissions are needed.

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?

Three short sentences with the operation, the surprising field mapping, and the scope limits each front-loaded and given exactly one sentence. No filler or restatement of the title.

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?

An output schema exists so return values need no explanation, and scope plus the product_key mapping are covered. But for a 17-parameter write tool with no schema descriptions, the required action_name and the create/update discriminator are left unexplained, which is a meaningful gap.

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

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

Schema description coverage is 0% across 17 parameters, so the description must carry the burden, yet it only explains one field (product_key's serial mapping). The single required parameter, action_name, is never explained and has no enum, leaving the create-vs-update mechanism entirely opaque; the many id fields (license_id, company_id, category_id) are also unqualified.

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 pair (create or update) and resource (Snipe-IT software licence), which cleanly separates it from licenses_search, license_seats and delete_resource. An agent can identify the operation without opening 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?

'Use only for explicit writes' gives a positive usage condition, and the closing sentence carves out two clear exclusions (no deletion, no seat assignment) that implicitly route to delete_resource and license_seats. It does not name those alternative tools explicitly, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and idempotentHint=true, so the safety profile is covered. The description adds a concrete scope boundary ('cannot modify memberships or delete records') beyond the generic destructive hint, but otherwise restates the annotation and offers no auth, rate-limit, or 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?

Three short sentences, front-loaded with purpose, then the discriminator, then the return/safety note. The value list for organization_type is slightly redundant with the earlier enumeration but nothing is padded.

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?

An output schema exists, so return-value explanation is not required, and annotations cover safety. However, for a 9-parameter tool with 0% schema coverage and an undocumented action_name mode switch, the description leaves too much of the calling contract to inference.

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% across 9 parameters, so the description must carry the burden. It documents only organization_type and its allowed values; query, limit, offset, item_id, company_id, manager_id, location_id and especially action_name (default 'list', which appears to control mode) are left entirely unexplained.

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 specific verbs (list/search/retrieve) plus the exact resource set (Snipe-IT companies, departments, permission groups), and implicitly separates itself from the sibling organization_write by declaring it read-only. An agent can distinguish it from organization_write without opening either 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?

It names the discriminator parameter and its three values (company, department, group), which is real routing guidance, and the read-only statement hints at when to prefer organization_write. But it never explicitly says when to choose this tool over its write sibling, and gives no prerequisites or 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?

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the useful constraint that deletion is out of scope and that permissions arrive as a JSON object, but says nothing about required permissions, validation failures, or what an update overwrites. With annotations carrying the safety burden, this is adequate but not 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?

Four short sentences, front-loaded with the create/update scope and with no filler. Slightly fragmented, but every sentence contributes a distinct fact.

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?

An output schema exists so return values need no explanation, and annotations cover the mutation profile. However, for a 9-parameter write tool with 0% schema coverage, the description leaves too much parameter meaning (action_name, organization_type values, update overwrite behavior) to inference.

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% across 9 parameters, so the description must carry the full burden. It only hints at relationship fields generally and clarifies permissions_json, while the required action_name and organization_type (with no enum listed) and the distinction between item_id, company_id, and manager_id remain unexplained.

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 pair (create or update) and the exact resources it targets (Snipe-IT company, department, or group), and explicitly excludes delete. An agent can tell this apart from organization_search (read) and delete_resource (removal) without opening any 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?

"Use only for requested writes" gives a clear when-to-use condition, and "cannot delete" establishes a when-not boundary that routes deletion elsewhere. It stops short of naming the alternative tool, so it is strong but not fully explicit.

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, destructiveHint=false, and openWorldHint, so the safety profile is fully covered. The description reinforces this ('never audits or changes records') and adds a note about advertised return fields, but offers no pagination, rate-limit, or response-shape detail beyond the existing output schema.

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

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

Two sentences, front-loaded with the report list, with no filler. The second sentence about advertised result fields is slightly vague but does not bloat the definition.

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

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

For an 11-parameter multi-action tool with a required action_name and 0% schema coverage, the description omits the one thing an agent most needs: the valid action values and how they map to the listed reports. The presence of an output schema covers return values, but the input side is inadequately specified.

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% across 11 parameters, and the description does not explain any of them. It never defines what action_name values are valid, nor what item_id, user_id, target_id, action_filter, item_type, or the date range parameters do, leaving the agent to guess at the required routing 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 names a specific verb ('Read') and enumerates the concrete report families the tool produces: activity, item history, checkout/checkin history, status summaries, depreciation, and due/overdue assets. An agent gets a clear sense of what it returns, though it never distinguishes itself from siblings like assets_search or inventory_search that could overlap.

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

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

Usage is implied by the enumerated report types, and 'This tool never audits or changes records' acts as a mild when-not signal. However, there is no explicit guidance on when to choose this tool over asset_lifecycle, assets_search, or inventory_search, and the action_name routing that selects among report types is left unexplained.

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 readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real behavioral context: backup payloads are base64-encoded only when within max_inline_bytes (implying truncation/bounding otherwise), and it explicitly disclaims settings changes and deletions. This goes beyond restating 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?

Three sentences: purpose first, then the base64/bounding constraint, then a negative scope statement. Front-loaded and mostly waste-free, though the negative clause partly duplicates the readOnly annotation.

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?

An output schema exists so return values need not be described, and annotations cover the safety profile. The three operational modes and the inline-size constraint are stated, leaving only the pagination params unaddressed.

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% across 5 params, so the description carries the burden. It explains action_name's modes and the meaning of max_inline_bytes, but leaves limit and offset (pagination) and backup_filename's exact usage undocumented. Partial compensation only.

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 (Read) plus the resource (Snipe-IT version/system info and backups) and enumerates the three supported modes: version data, list backups, download one backup. No sibling tool competes for this resource, so it is easily distinguishable, though it never explicitly names 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?

Gives a hint for one mode ('Version data supports capability diagnosis') and a constraint for the download mode, but never explains when to choose version vs list vs download; the routing is left to the reader to infer from action_name. No exclusions or explicit alternatives are provided.

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

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

Annotations already cover readOnly/idempotent/non-destructive, so 'This tool is read-only' is largely redundant. The description does add value beyond the structured fields: it discloses the breadth of what is returned, the optional EULA inclusion, and that assets follow the same normalization as assets_search with specific fields.

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?

Three tight sentences that front-load the core purpose and then qualify scope. Nothing is padded, though the field enumeration is somewhat list-heavy.

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?

An output schema exists so return values need not be spelled out, and the description reasonably covers retrieval scope. However, for a four-parameter read tool the identification semantics (which identifier to pass) and sibling disambiguation remain unexplained, leaving an agent to infer call mechanics.

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% across four parameters, so the description carries the burden and only partially succeeds. 'Unambiguously identified user' hints that one of email/user_id/username is used for identification but never says which, whether they are alternatives or all required; 'optional EULA' loosely maps to include_eulas but is not tied to the flag.

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 ('Retrieve everything assigned to one unambiguously identified user in one call') and enumerates the categories returned (assets, accessories, licences, consumables, EULAs). It partially distinguishes itself from siblings by citing the assets_search normalization, though it never contrasts with inventory_search directly.

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: the 'in one call' phrasing suggests this is the batched alternative to per-category lookups, but there is no explicit 'use this when...' or 'use X instead when...' statement. No prerequisites (e.g., needing at least one identifier) are given.

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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds one genuinely useful behavioral trait beyond that – soft-deleted records are queryable ('including deleted-user queries') – but omits pagination behavior, auth requirements, and rate limits. A 3 is appropriate given annotations carry most of the load.

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?

Three tight sentences, front-loaded with purpose before scope and the exclusion. The opening verb list ('list, search, retrieve, or identify') is slightly padded, but no sentence is wasted.

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

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

An output schema exists so return values needn't be explained, and annotations cover the safety profile. However, for a 14-parameter tool with zero schema coverage, the description leaves roughly half the parameters (pagination, sort, query, user_id, action_name) unexplained, which is a real gap 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 across 14 parameters, the description must compensate. It names the core filter params (email, username, employee number, organisation/deleted) but leaves sort, order, limit, offset, query, user_id, and action_name entirely undocumented in both schema and prose.

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 clear verbs (list/search/retrieve) and the resource (Snipe-IT users), and routes the agent away from writes with 'Do not use for writes or deletion'. However, the phrase 'the current authenticated Snipe-IT user' conflicts with the broad filter set (email, username, employee_num, company_id, user_id), making it ambiguous whether this is a self-lookup or a general user search.

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?

Provides an explicit exclusion ('Do not use for writes or deletion') that effectively steers the agent to users_write, plus a clear statement of the supported filter dimensions. It never names the alternative tool directly and gives no prerequisites, so it falls short of a full 5.

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

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

Annotations already declare destructiveHint=true and non-idempotent, but the description adds real context beyond them: reset_2fa is flagged as a high-impact security action requiring explicit user intent, and deletion is explicitly out of scope. It stops short of describing what gets overwritten on update or any auth requirements.

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

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

Three short sentences, front-loaded with the action set and immediately followed by the decision rule and the exclusion. No filler or repetition.

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

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

For a 19-parameter mutation tool with 0% schema description coverage, the description omits all field-level guidance needed to actually invoke it correctly (which fields are required per action, password_confirmation pairing, etc.). Output schema covers returns, so that is not a gap, but parameter completeness is not.

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% across 19 parameters with no enums declared. The description names the action values (create, update, restore, reset_2fa) but explains nothing about which of the 18 data fields apply to which action or how user_id versus creating a new user works, so it fails to compensate for the 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?

States specific verbs and resource: create/update/restore/reset-2FA for a Snipe-IT user, and explicitly excludes deletion. An agent can distinguish this from users_search and delete_resource without opening any 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?

Gives a clear rule for choosing reset_2fa ('only when the user explicitly asks') versus the routine create/update/restore path, and states the tool cannot delete. It does not name sibling tools (e.g. users_search for reads), so routing is implied rather than fully explicit.

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