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

Annotations already declare the write/non-destructive profile. The description earns some credit by disclosing that this tool can move the asset and schedule the next audit, i.e. it mutates asset state beyond the audit record itself. It omits whether prior audit history is replaced, what is returned, and whether the location change requires the asset to be in a particular state.

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

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

One front-loaded sentence with no filler. It is arguably a touch too terse for a five-parameter mutation, but every clause is load-bearing.

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?

Missing note coverage and the update_location default of true would be a real risk for an agent omitting location_id — but with the update_location parameter defaulting to true and the description saying the move is optional, the risk is modest. No output schema exists, so return semantics remain unstated.

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

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

Schema coverage is 60%; 'note' and 'location_id' have no descriptions anywhere. The description does explain the move and next-audit-date options, but never mentions 'note' or clarifies that moving only occurs when update_location is true — the very coupling an agent could get wrong.

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?

Specific verb+resource ('Record an audit') on a specific object type ('hardware asset'), plus the two optional side effects it performs. It reads clearly against siblings like update/checkout/checkin, though it doesn't explicitly name which sibling to use instead for pure location moves.

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

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

No guidance on when to choose this over update (moving a location) or checkin/checkout. The word 'optionally' hints that location change is conditional, but the condition (the update_location flag) is never stated in usage terms.

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

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

The annotations already disclose readOnlyHint=false and destructiveHint=false, so the agent knows this is a non-read-only but non-destructive mutation. The description adds the core check-in behavior, but it does not describe side effects such as status/location changes, quantity handling, permissions, idempotency, or failure modes.

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

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

The description is front-loaded and extremely terse, with no filler. Every clause provides actionable resource-specific guidance.

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

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

For an 8-parameter mutation with only minimal annotations and no output schema, the description covers the critical from_user_id/from_asset_id mapping for several resource types. It is not complete enough, however, because consumables are left undocumented and optional parameter behavior and mutation side effects are not addressed.

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

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

The description adds important conditional parameter meaning beyond the schema by specifying that hardware needs just the id, accessories/licenses use from_user_id or from_asset_id for licenses, and components use from_asset_id. However, it omits the consumables resource entirely and does not explain optional fields such as note, quantity, status_id, or location_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 states a specific verb and resource: 'Check an item back in.' The phrase 'back in' implies the reverse of the sibling checkout operation, but it does not explicitly name checkout or otherwise distinguish itself from that sibling.

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

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

The description implies when to use it by saying 'back in,' but it never explicitly says this is for returning previously checked-out items or when to prefer it over checkout/update/delete. It provides per-resource invocation guidance, which is useful but is more parameter mapping than usage selection.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so safety is covered. The description adds genuine behavioral detail with 'first free seat is used' for licenses, but says nothing about failure modes (item already checked out, no free seat) or permission 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?

One verb sentence followed by a dense, scannable mapping expression. Zero filler and the operation is front-loaded before the constraint matrix.

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 9-parameter mutation with no output schema and thin annotations, the description covers the highest-risk ambiguity (which target type each resource accepts). It omits error behavior and quantity semantics for consumables, which an agent may still need.

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 67%, so the schema carries most of the load, but the description adds meaning the schema does not: the resource->target matrix clarifies the relationship between 'resource', 'to' and 'target_id', and 'first free seat' explains license behavior. It leaves 'name', 'note', 'quantity' and 'expected_checkin' entirely to the schema.

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

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

States a specific verb and resource ('Check an item out') and immediately disambiguates it from the checkin sibling by naming the operation's direction. The resource->target matrix makes clear exactly which combinations this tool handles.

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 matrix effectively encodes when each resource/target combination is valid, which is real usage guidance an agent would otherwise have to guess. It stops short of naming alternatives or exclusions (e.g., use checkin to reverse, or what to do if a license has no free seat).

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 and destructiveHint=false, so the write/non-destructive nature is covered. The description adds the describe-first dependency, but says nothing about failure modes (missing required fields, invalid resource), permission requirements, or whether partial data is rejected.

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 terse, front-loaded sentences with no filler. It borders on under-specified rather than wasteful, which is the right failure direction for a compact 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?

Given a nested free-form `data` object, 18 resource types, and no output schema, the description is thin: it delegates all field knowledge to `describe` but doesn't say what a successful call returns (e.g., new ID) or how resource-specific required fields differ. The describe-first pointer is the key dependency and it is present, so it is minimum-viable rather than inadequate.

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

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

Schema coverage is 50%; `data` is opaque free-form with only "see describe" in the schema, and the description reinforces that pointer rather than adding field-level meaning. The `resource` enum is self-documenting in the schema, so the description contributes little beyond what structured fields already carry.

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 (create) and resource (a Snipe-IT record), with the `resource` enum making the domain concrete. It is distinguishable from update/delete/restore siblings by the verb, but the description itself never names or contrasts an alternative.

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?

Explicitly prescribes a prerequisite workflow: "Call describe first for required fields." That is a real routing instruction an agent needs, but there are no when-not-to-use conditions and no mention of validation or duplicate-handling alternatives.

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

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

Annotations already declare destructiveHint=true, so the destructive nature is known; the description adds real value beyond that by disclosing that deletion is soft (reversible via restore) where Snipe-IT supports it, and that confirm: true is mandatory. It leaves open which resources fall back to hard delete and whether related records cascade, which is the main remaining behavioral gap.

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

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

A single sentence with the destructive action front-loaded, followed by the reversibility caveat and the confirm requirement. No waste and nothing buried.

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, no-output-schema tool the description covers the essentials (soft delete, restore path, confirm gate), but with 0% param documentation it omits what 'resource' means and what 'id' refers to, and says nothing about permissions or side effects on linked records.

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 carry parameter meaning, but it only explains 'confirm'. The 'resource' enum (18 entity types) and the 'id' parameter are undocumented in both description and schema, leaving two of three required parameters 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 and resource ('Delete a Snipe-IT record') and names the sibling it relates to ('see restore'), so an agent knows this is the destructive counterpart to restore. It doesn't mention that 'record' spans 18 resource types, but the core action is unambiguous.

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

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

The description signals the recovery path ('soft delete ... see restore') and states the hard precondition 'Requires confirm: true', which is exactly the guidance an agent needs before invoking a destructive tool. It doesn't cover when deletion is inappropriate (e.g. records still checked out) or permission requirements.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful scope: it returns accepted create/update fields and list filters, with special behavior for hardware custom fields, but does not describe return shape, permissions, or 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?

Two short sentences, front-loaded with the core purpose, and the hardware exception is stated without wasted text.

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

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

The description is adequate for a simple read-only introspection tool, but with no output schema it should say more about what is returned, such as field names, types, or filter metadata. It also leaves the resource enum semantics largely implicit.

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 carry parameter meaning. It mentions 'a resource' and hardware-specific behavior, but does not explain the resource parameter or the 19 enum values beyond what the schema already lists.

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 capability: returning fields accepted by create/update plus list filters for a resource, and notes hardware-specific custom fields. It distinguishes itself reasonably from CRUD siblings, though it does not explicitly contrast with list/get/lookup.

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

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

Usage is implied: an agent can infer it should call describe to learn valid fields before create/update or to discover list filters. However, there is no explicit when-to-use guidance or comparison against alternatives like get or list.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that: it does not describe return shape, whether it errors on missing records, permission requirements, or what the `raw` flag changes about the response.

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

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

A single front-loaded sentence with zero filler, which is structurally clean. It is arguably thinner than a tool spanning 18 resource types warrants, 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?

For a 3-parameter tool with 0% schema coverage, a wide resource enum, no output schema, and a cryptic `raw` flag, the description leaves too much to inference. It never explains the resource scope, the raw mode, or what a successful vs. failed fetch looks like.

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 carry parameter meaning — but it only restates that `id` is numeric. The `resource` enum (18 record types) and especially the `raw` boolean are unexplained, leaving an agent to guess what `raw: true` produces.

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?

"Fetch one Snipe-IT record by numeric id" supplies a concrete verb (fetch), a resource (record), and the lookup key (numeric id). The singular "one record" implicitly contrasts with the sibling `list`, though no sibling is named explicitly, so it sits below a fully distinguishing 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 statement about when to use this versus `list`, `lookup`, `describe`, or `audit`. The only hint is the implied "use when you already have a numeric id," and no exclusions or prerequisites are given despite eleven closely related siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds real value on top: it discloses the return envelope {total, offset, rows}, the user_id scoping behavior, and the fact that filters are arbitrary resource-specific pass-throughs (important, non-obvious behavior). It omits pagination defaults and any rate-limit notes.

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 no waste: purpose first, return shape second, the two parameter behaviors third. Every sentence carries information an agent needs.

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

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

With no output schema, the description correctly compensates by naming the return shape. A 19-value resource enum and 9 params are handled adequately, though the meaning of 'resource' values and pagination defaults could be spelled out more.

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

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

Schema description coverage is only 33% across 9 parameters, and the description only meaningfully explains user_id, filters, and search; sort, order, limit, offset, and raw are left to the schema or undocumented. The user_id note does add a real constraint beyond the schema (only hardware/accessories/licenses apply), which earns it above a 2.

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 ('List or search Snipe-IT records of one resource type') and scopes it to a single collection, which implicitly separates it from the singular 'get' sibling. It does not explicitly name an alternative, but the scope is unambiguous.

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

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

Gives two concrete usage rules: pass user_id to retrieve a user's checked-out hardware/accessories/licenses, and use filters for resource-specific query params with a pointer to 'describe' for the valid keys. No explicit exclusion against 'get' or 'lookup', so it stops 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 and destructiveHint=false, so the safety profile is covered. The description adds useful output context ('full records with numeric ids') that no output schema provides, but omits what happens when no match is found and whether multiple identifiers may be combined.

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

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

A single sentence with zero waste, leading with the verb and the lookup keys. Every clause carries information not available in the 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?

Reasonable for a read-only resolve tool, but with five all-optional parameters and no output schema an agent still needs to know resolution rules for ambiguous or multi-identifier calls and the not-found behavior.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does map all five parameters to their entity types (asset_tag/serial to asset, username/email/employee_num to user). It does not state mutual exclusivity or that one identifier is required, which the schema leaves as five optional properties.

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?

A specific verb ('Resolve') plus explicit resources (hardware asset, user) and the key types that select between them. An agent can tell it apart from 'get'/'list' by the natural-key lookup framing, though no sibling is named to make the contrast 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?

The identifier lists imply when to use it (when you hold a tag, serial, username, email, or employee number rather than an id), but no alternative is named and no when-not condition is stated. Usage must be inferred.

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, and destructiveHint=false, so the safety profile is covered. The description adds meaningful context by clarifying that this reverses a soft delete rather than recreating a record, but says nothing about permissions, error behavior for non-deleted ids, or what the response contains.

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

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

Two short sentences with the action front-loaded and no filler. The second sentence is compact but its resource list is the weakest part and does not earn its place given the schema enum.

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

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

For a two-parameter mutation with no output schema, the description covers the core semantics of soft-delete restoration. It is still missing prerequisites (record must be soft-deleted), permission expectations, and confirmation of what a successful restore returns.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it does not explain the id (integer, positive) or the resource enum. Worse, its claim that restore works for hardware, users, models and manufacturers conflicts with an enum offering eighteen resources, which could steer an agent away from valid calls.

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?

"Restore a soft-deleted record" states a specific verb and resource, and "soft-deleted" distinguishes it from create/update siblings. The second sentence, however, narrows support to four resource types when the schema enum lists eighteen, which muddies the stated scope.

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

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

There is no explicit when-to-use guidance, no mention of how to obtain the id of a deleted record, and no routing against siblings like delete, update, or create. The only implied usage comes from the word "soft-deleted".

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, and destructiveHint=false. The description's one contribution beyond that is the PATCH-style partial-update semantics, which is genuinely useful. It says nothing about how invalid or unknown fields are handled, permission requirements, or error behavior.

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

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

One front-loaded sentence with no filler and the partial-update constraint in parentheses. It is efficient but borders on under-specified rather than deliberately tight.

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 polymorphic mutation tool with a free-form nested 'data' object, no output schema, and 33% schema coverage, the description leaves out valid-field discovery, required fields, and failure modes. An agent cannot safely call it without opening every other schema.

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

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

Schema description coverage is only 33%, so the description needs to compensate and does not: it never explains the 'resource' enum, the role of 'id', or the shape of 'data'. The pointer to valid fields lives in the schema ('see describe'), not the 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?

States a specific verb and effect ('Partially update a Snipe-IT record') plus the key semantic that only given fields change. It does not differentiate from siblings like create/restore beyond the obvious verb, and never mentions that 'record' spans 18 resource types.

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

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

No guidance on when to use this versus create, restore, or checkout/checkin, and no prerequisite telling the agent to call describe to learn valid field names. Usage is only inferable from the verb.

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