manage_locations

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

Annotations already indicate destructive behavior (destructiveHint=true), so the description does not need to repeat that. However, it adds no additional behavioral context such as side effects of deleting a location, permission requirements, irreversibility, or implications for associated assets. The description mostly restates action outcomes ('delete: Delete a location') without deeper disclosure.

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 well-organized with a brief intro, a bulleted list of operations, and a return-type statement. It is front-loaded with the tool's purpose and uses compact phrasing. No wasted sentences, though the operations list is somewhat lengthy but necessary 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 the complex multi-action tool and rich schema/annotations, the description covers all operations with their required parameters and a return-type summary. It does not explain edge cases like pagination or sorting nuances, but the schema covers those details. It lacks explicit usage guidance but is otherwise complete for selecting actions.

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

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

The schema has 100% parameter description coverage, so the baseline is 3. The description adds useful per-action requirements, notably that create requires location_data with name and that assets/users require location_id. However, it states update 'requires location_id and location_data', which contradicts the schema's 'optional for update' designation, creating potential confusion for agents.

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 manages Snipe-IT locations and enumerates CRUD operations plus asset/user listing. While the verb 'Manage' is broad, the operation list provides specific actions and the resource 'locations' distinguishes it from sibling tools like manage_assets and manage_users.

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

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

The description implies usage for location management with a brief context sentence ('Locations represent physical places where assets are stored or deployed'), and the operation list suggests when to use each action. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions for other resource-specific tools.

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