Undo a wrong product merge by moving selected food records into their own product; matching never rejoins them, and the decision maker is noted.
Undo a wrong merge: move source records out of a product into one of their own. Matching never
joins them with the rest again. by names who decided.
| Name | Required | Description | Default |
|---|---|---|---|
| by | Yes | ||
| note | No | ||
| food_ids | Yes | ||
| product_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does disclose one important trait beyond the schema: the split is sticky ("Matching never joins them with the rest again"), and it notes that `by` records the decision-maker. However, it never states whether the operation is reversible, what happens to the original product if it is emptied, or whether special permissions are required — meaningful gaps for a write operation.
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, purpose front-loaded, no filler. The middle sentence ("Matching never joins them with the rest again") is a little cryptic in phrasing, which slightly blunts the structure, 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 values need not be described. Given a 4-parameter mutation tool with zero annotation coverage and 0% schema description coverage, the description covers purpose and one key behavior but leaves parameter semantics and mutation side effects (reversibility, fate of the source product, auth) insufficiently 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 description coverage is 0%, so the description must carry all parameter meaning. It explains only `by` ("names who decided"); `note` is entirely undocumented, and `food_ids`/`product_id` are only loosely implied by "source records out of a product." Half the 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 names a concrete verb+resource: moving source records out of a product into their own product, framed as undoing a bad merge. That is specific enough to distinguish it from the read-oriented siblings (get_food, search_foods, get_product_by_barcode). It stops short of naming the counterpart merge operation or any sibling, 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?
"Undo a wrong merge" implies the triggering situation, so usage is inferable, but there is no explicit when-to-use vs. when-not, no mention of prerequisites (e.g., needing review-queue approval, given the decide_review/review_queue siblings), and no named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.