Skip to main content
Glama

Change My Gear

edit_my_gear
Destructive

Changes the connector's account's My Gear, in one call. add puts new pieces in; one the account already holds (same brand, name and variant) comes back as already_have and is left as it was. update changes pieces by the ids get_my_gear gives, only the fields sent, null clearing one. A piece that names a catalog_id, as it is added or later, is linked to that catalog row and takes its brand, name, variant, gear type and weight where none were given; null unlinks it. remove puts pieces away by id: they stop being offered on lists, and the lists that still carry them will not bring them back. restore brings put-away pieces back. Each piece answers for itself, in the order sent. What is added or changed here counts as the owner's own word on the piece, so a list saved later cannot overwrite it. Needs a read-and-change access token.

Input Schema

NameRequiredDescriptionDefault
addNoNew pieces.
removeNoIds of pieces to put away.
updateNoChanges to pieces that exist, each by id.
restoreNoIds of put-away pieces to bring back.

Output Schema

NameRequiredDescriptionDefault
addedYesPieces that were new to My Gear.
removedYesOne per id in remove, then one per id in restore, in the order sent.
resultsYesOne per piece in add, in the order sent.
updatedYesOne per entry in update, in the order sent.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.6/5.0
Behavior5/5

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

It adds substantial behavior beyond the annotations: duplicate adds return already_have and leave the piece unchanged, update changes only the fields sent with null clearing, catalog_id links and inherits catalog fields, remove hides pieces from lists, and restore reverses that. It also discloses ordering semantics and the access-token requirement.

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

Conciseness4/5

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

The description is front-loaded with the core action and then proceeds through the operations in a logical order. It is dense and uses long compound sentences, but nearly every sentence carries useful behavioral information.

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

Completeness5/5

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

Given the four operations, full schema coverage, annotations and an output schema, the description covers the important missing context: duplicate handling, null clearing, catalog inheritance, remove/restore semantics, per-piece ordering, and owner precedence. An agent has enough information to invoke it correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents individual fields. The description adds cross-parameter meaning: add detects duplicates by same brand, name and variant; update uses ids from get_my_gear and only changes sent fields; catalog_id links or unlinks a catalog row and inherits its fields.

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

Purpose5/5

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

The description states a specific verb and resource: it changes the connector account's My Gear in one call, and it enumerates add, update, remove and restore. It also distinguishes the tool from get_my_gear by explaining that update uses ids that get_my_gear returns.

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

Usage Guidelines4/5

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

The description clearly explains what each operation is for, including adding new pieces, updating existing pieces by id, putting pieces away, and restoring put-away pieces. It does not explicitly compare this tool against sibling alternatives beyond mentioning get_my_gear as the source of ids and search_catalog as the source of catalog rows.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.