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

Adds 'append-only log entry' beyond annotations (non-destructive, write), but does not clarify idempotency or return 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?

Two efficiently front-loaded sentences with no wasted words.

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

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

No output schema or return value description, leaving a gap for a write tool with simple parameters.

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?

Compensates partially for low schema coverage (25%) by mentioning locationId and nextAuditDate, but overlooks note 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?

Clearly states the action 'Record a physical audit' on an 'asset', with 'append-only log entry' distinguishing it from update or checkin/checkout 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?

Implies usage for physical audits, but lacks explicit when-not-to-use or alternatives like 'for non-physical audits, use update_asset'.

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 indicate readOnlyHint=false and destructiveHint=false, but the description adds critical behavioral details like permanent seat burning for non-reassignable licenses and the need for write access, going beyond what annotations provide.

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?

Description is efficiently structured with two clear sentences followed by a GOTCHA and notes, though the gotcha section is slightly dense; still front-loaded with purpose and key constraints.

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?

Covers essential behavioral traits, parameter nuances, and constraints for a complex check-in tool with 7 parameters and no output schema, though omits return value information and could elaborate on error conditions.

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 57% schema coverage, the description adds meaning to the id parameter (specifying it's a pivot-row id for accessory/component), clarifies that seatId is required for license, and notes the default quantity for component checkin, compensating for schema gaps.

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

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

Clearly states the verb 'check in' and lists the specific resource types (asset, accessory, component, license) while explicitly excluding consumables, effectively distinguishing from sibling tools like snipeit_checkout.

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 explicit guidance on when to use this tool, including a GOTCHA for id interpretation, license seatId requirement, permanent seat burning on non-reassignable licenses, and write access prerequisite, aiding correct 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?

Description states consumable checkout is irreversible, which contradicts the annotation 'destructiveHint: false' (irreversible operations are destructive). Annotations already indicate not read-only and not idempotent, but the contradiction downgrades this dimension.

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?

Description is dense but efficient, conveying complex mapping in one paragraph. It front-loads the main action. Could be slightly more structured with bullet points for clarity.

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 9 parameters and complex type-specific rules, the description covers the essential mappings. However, it lacks information about return values or success behavior (no output schema), and some parameter details (note, expectedCheckin format) are left to the 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?

With 67% schema coverage, the description adds significant meaning beyond the schema: it explains which target types are valid per item type (e.g., 'component → asset') and notes optional seatId for licenses. This compensates for the missing schema descriptions on 3 parameters.

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

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

Description clearly states the tool's purpose: checking out items to entities (asset, accessory, consumable, component, license). It provides specific mappings per type (e.g., 'asset → user/asset/location') and distinguishes from the sibling 'checkin' tool (opposite operation).

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

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

Description specifies that consumable checkouts are irreversible and requires user confirmation, and notes that write access is needed. It implicitly contrasts with the checkin sibling but does not explicitly state when to avoid this tool or provide 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?

Description states write operation and access requirement. Annotations indicate non-read-only, non-destructive, non-idempotent, open-world. No contradictions; description adds value beyond annotations.

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

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

Two sentences impart essential information with no wasted words. Front-loaded with core purpose.

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?

Covers minimum fields and access, but missing return value info. For a creation tool, describing the response (e.g., asset ID) would enhance completeness.

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

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

Schema coverage is 100% but schema is vague (single payload object). Description compensates by specifying key fields (model_id, status_id, asset_tag) that are implicitly required.

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?

Title and description clearly state 'Create a hardware asset' with specific verb and resource. Distinguishes from siblings like snipeit_update_asset and snipeit_list_assets.

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 minimum required fields (model_id, status_id, optional asset_tag) and access requirement (write access). Lacks explicit when-not-to-use but context suffices.

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

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

Annotations already indicate write operation (readOnlyHint=false) and non-destructive. Description adds 'Requires write access', confirming permission need. No details on idempotency, error handling, or specific behavioral traits beyond what annotations provide. Minimal extra value.

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?

Extremely concise: one sentence listing entity types plus 'Requires write access'. No fluff, front-loaded with purpose. Every word earns its place.

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

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

Tool is complex (multiple entity types, nested payload, no output schema). Description lacks explanation of return values, payload construction guidance, or error scenarios. Incomplete for effective use.

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?

Input schema has 100% description coverage, so baseline is 3. Description does not add parameter details beyond the schema; it only lists example entity types already in schema. No guidance on payload structure.

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

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

Description clearly states verb (Create) and resource (non-asset entity) with examples, and distinguishes from sibling tool snipeit_create_asset by specifying 'non-asset'. This provides precise purpose and 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?

While not explicitly stating alternatives, the description's phrase 'non-asset entity' and the schema's entity enumeration (with note that assets have their own tools) implicitly guide agents to use this tool for non-asset creation. 'Requires write access' gives a prerequisite. Could be improved with explicit when-to-use.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds behavioral context by naming the types of actions in the trail, but does not disclose pagination behavior, rate limits, or any other side effects. Consistent with annotations.

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

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

Two sentences: the first defines purpose, the second lists filters. Concise and front-loaded with no extraneous text. Could benefit from slightly more structure but is efficient.

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 7 parameters, no output schema, and only moderate schema coverage, the description is too brief. It does not explain return format, pagination (despite limit/offset parameters), or how filters interact. A more complete description would improve usability for a list-query 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 43% (3 of 7 parameters have descriptions). The description mentions filtering by item, action type, and target, which loosely maps to parameters, but does not add meaning for undocumented parameters like itemId, offset, targetId. The baseline is 3, and the description does not significantly compensate.

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

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

The description clearly defines the tool as retrieving the Snipe-IT audit trail, listing specific action types (checkouts, checkins, creates, updates, audits) and mentioning filtering options. It distinguishes this from sibling tools like snipeit_list_assets which list resources rather than activity logs.

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 does not provide explicit guidance on when to use this tool versus alternatives like snipeit_search_capabilities or snipeit_list_assets. No when-not or exclusion criteria are mentioned. The usage context is implied but not clarified.

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, etc. Description adds value by specifying query flexibility (multiple identifiers) and the id-include behavior, but does not disclose potential rate limits or 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?

Two succinct sentences: first covers core purpose, second adds specific detail on include parameter. No redundant 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?

Lacks description of return value (asset object), error handling, and behavior when multiple identifiers are provided. With no output schema, this gap is notable.

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 coverage, description adds meaning by naming parameters and explaining include options, but does not clarify mutual exclusivity, required identifier, or formatting of assetTag/serial.

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

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

Description clearly states the verb 'Fetch', resource 'one asset', and identifiers (id, assetTag, serial). It distinguishes from list tools and explicitly mentions optional inclusion of related entities.

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?

Description provides context on when to use (fetch single asset by identifier) but lacks explicit guidance on when not to use or alternatives like list_assets for bulk queries.

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, openWorldHint, idempotentHint, and destructiveHint false. The description adds behavioral details about fetching by ID and subresource inclusion patterns, which are not covered by annotations. No contradictions.

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

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

The description is a single sentence with examples, front-loading the core purpose. It is moderately concise; could be slightly more structured (e.g., separate lines for examples) but is effective and wastes little space.

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

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

Given the lack of an output schema and moderate parameter count, the description covers the key aspects: fetching by ID, subresource inclusion, and example patterns. It does not describe return structure, but for a simple get operation, this is acceptable. The annotations fill gaps on safety and idempotency.

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

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

Schema coverage is only 33% (entity has a description). The description compensates by explaining the 'include' parameter with concrete examples for multiple entity types. The 'id' parameter is not elaborated, but its purpose is obvious from context. Overall, the description adds significant meaning beyond the schema.

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

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

The description clearly states the tool fetches one entity by ID or a subresource via include, with specific examples. It distinguishes from siblings like snipeit_get_asset (for assets/hardware) by noting that assets have their own tools, and from snipeit_list_entities by focusing on a single entity retrieval.

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

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

The description provides explicit examples of when to use the include parameter for different entity types (e.g., licenses include=seats). However, it does not explicitly state when NOT to use this tool versus alternatives like snipeit_list_entities, though the context suggests it is for single entity or subresource 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 indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds value by specifying response shape ({total, rows}) and pagination via limit/offset, plus the behavior of the 'due' parameter. No contradictions.

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 packing essential info: purpose, filter list, special parameter, and response format. Could be more structured with bullet points, but still clear and efficient.

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

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

For a list tool with 16 parameters and no output schema, description covers key aspects: filters, special behavior (due), response shape, and pagination. Mentions limit/offset but not typical pagination handling like total counts. Good but not exhaustive.

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 has 16 parameters with only 6% description coverage. Description groups filters (search, status IDs, etc.) but does not explain each parameter in detail. Some compensation, but lacks depth for parameters like assignedType or orderNumber.

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

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

The description uses specific verb 'Search/list' with clear resource 'hardware assets'. It distinguishes from siblings like snipeit_get_asset (single asset) and snipeit_list_entities (other entities) by focusing on asset listing and filtering.

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 clear context for when to use: searching and listing assets with various filters. Mentions special use case for 'due' parameter. Does not explicitly state when not to use or compare to alternatives, but siblings list helps differentiate.

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, destructiveHint=false, so the read-only and safe behavior is clear. The description adds only the basic response format {total, rows} but does not disclose other behaviors such as pagination behavior, rate limits, or handling of unknown entities. Given strong annotation coverage, this score is adequate.

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

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

The description is a single sentence listing entities and the response format, which is concise and front-loaded. However, it could be structured better with bullet points or more explicit sections to improve readability without increasing length.

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 response format is mentioned, which is helpful given no output schema. However, the description omits details on pagination (limit/offset), sorting, searching, and the default behavior (e.g., default limit 50). With 6 parameters and only 33% schema coverage, the description is not sufficiently complete to guide an agent without external knowledge.

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% (only limit and entity have descriptions). The tool description adds no parameter information beyond what is in the schema. It does not explain 'sort', 'order', 'offset', or 'search' parameters, leaving agents without guidance on how to use pagination, filtering, or ordering.

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

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

The description clearly states the verb 'List' and enumerates all entity types that can be listed. It also distinguishes from assets/hardware by noting they have their own tools, which differentiates it from sibling snipeit_list_assets.

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 implicitly suggests when to use this tool (for entities other than assets/hardware) by mentioning in the entity parameter description that assets/hardware have their own tools. However, it lacks explicit guidance on when not to use, or criteria for choosing between alternatives like snipeit_list_assets or snipeit_search_capabilities.

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

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

Annotations already declare readOnlyHint and destructiveHint; description adds minimal extra behavioral context (returns examples) but does not elaborate on other aspects.

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?

Single concise sentence that front-loads the purpose with no 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?

Lacks detail on response format and parameter usage; while simple, the description is vague about what 'capabilities and examples' entails.

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 description does not explain the limit or query parameters, leaving their semantics unclear.

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

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

Description clearly states it searches capabilities and examples, distinguishing it from sibling tools that perform specific actions.

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

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

Explicitly says 'Use this first when deciding which tool to call', providing clear when-to-use guidance.

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

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

The description explicitly states PATCH semantics ('only the fields in patch change') and that write access is required. This adds value beyond the annotations, which only indicate readOnlyHint=false. No contradictions with annotations.

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

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

The description is extremely concise at two sentences, with no wasted words. It front-loads the key information (partial update, PATCH semantics) in the first sentence.

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

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

Given the tool has 2 parameters (id and patch), no output schema, and no annotations beyond hints, the description covers the core behavior (partial update) and access requirement. However, it lacks details about return values, error cases, or id parameter constraints, making it minimally adequate.

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

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

The input schema has 50% description coverage (only the 'patch' parameter is described as 'Snipe-IT API fields (snake_case).'). The description adds that 'only the fields in patch change', clarifying the effect of the patch parameter but not its format. This provides moderate added meaning beyond the schema.

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

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

The description clearly states the action ('partially update an asset') and the resource ('asset'). It specifies PATCH semantics, which distinguishes it from full updates or create operations. However, it does not explicitly differentiate from the sibling snipeit_update_entity, which could be ambiguous.

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

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

No guidance is provided on when to use this tool versus alternatives like snipeit_create_asset or snipeit_get_asset. The description assumes the agent knows to use it for partial updates but lacks explicit when-to-use or when-not-to-use 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 indicate mutation (readOnlyHint=false) and non-idempotency (idempotentHint=false). The description adds the PATCH semantics detail and write access requirement, which is consistent and adds value without contradiction.

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: one for purpose and one for access requirement. No filler. Front-loaded with key action and resource. Every word earns its place.

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

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

Given the three parameters and no output schema, the description covers the core functionality and access need. It does not detail patch structure or error handling, but sibling differentiation and annotations fill some gaps. Adequate for a mutation tool with moderate complexity.

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

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

Schema coverage is 67% with descriptions for entity and patch. The description does not add detail beyond the schema for parameters. It mentions 'non-asset entity' which aligns with the entity enum description. No additional semantic guidance is provided for the patch object or 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 clearly states the verb (partially update), resource (non-asset entity), and HTTP semantics (PATCH). It distinguishes from asset-specific tools via the entity enum description referencing 'assets/hardware have their own tools'.

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

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

The description implies use for non-asset entities by noting assets have separate tools, and requires write access. It does not explicitly state when not to use or enumerate alternatives, but the context is sufficient for an agent.

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