Skip to main content
Glama
ilyautov

marketplaces-mcp-ru

ym_write_method

Create or update Yandex Market data by executing a cataloged write endpoint. No request is sent without an explicit confirm_write=true flag.

Instructions

Execute one WRITE endpoint from the catalog: create or update data.

Target API: https://yandex.ru/dev/market/partner-api/doc/ru/.

Requires confirm_write=true; nothing is sent without it. Irreversible operations live in ym_delete_method, reads in ym_call_method.

Args: operation_id: id from the catalog (see ym_search_methods). path_values: values for {placeholders} in the path. query: query-string parameters. body: JSON request body. confirm_write: must be true. Returns JSON: {"ok": true, "status", "data"} or the error envelope.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyNo
queryNo
path_valuesNo
operation_idYes
confirm_writeNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.1

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already indicate this is a mutation (readOnlyHint=false, destructiveHint=false), so the description's main added behavioral value is the confirm_write guard: 'nothing is sent without it.' It also discloses the response shape and target API. It stops short of describing auth requirements, rate limits, or side-effect granularity, but the annotation coverage lowers the burden; there is no contradiction.

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

Conciseness5/5

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

The description is compact and front-loaded: purpose, safety guard, sibling routing, then a scannable Args list and return envelope. Every sentence earns its place.

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

Completeness4/5

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

For a generic catalog-driven executor, it provides the essential loop: discover operation_id via ym_search_methods, supply path/query/body, and pass confirm_write=true. The output envelope is stated, and an output schema is present, so return-value detail isn't required. It could have explicitly pointed to ym_describe_method for per-endpoint parameter requirements, but the catalog pointer largely covers this.

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

Parameters5/5

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, and it does: operation_id comes from the catalog, path_values fill {placeholders}, query holds query-string parameters, body is the JSON request body, and confirm_write must be true. This adds significant meaning beyond the bare schema types.

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 names a specific action and resource: 'Execute one WRITE endpoint from the catalog: create or update data.' It further distinguishes itself from siblings by noting that irreversible operations live in ym_delete_method and reads in ym_call_method.

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

Usage Guidelines5/5

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

It gives an explicit precondition and safety rule: 'Requires confirm_write=true; nothing is sent without it.' It also tells the agent where to route other operation types (ym_delete_method for irreversible, ym_call_method for reads) and where to find operation IDs (ym_search_methods).

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

Deploy Server

Other Tools