Trendyol API isteği gönder

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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds real context beyond them: auth, User-Agent and sellerId are injected automatically from the store, "*" is read-only, and dryRun:true returns the built URL/body without sending. It does not discuss rate limits, error/partial-failure behavior across multiple stores, or retries.

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?

Information is front-loaded: the tool's purpose, then the auto-injected credentials, then the prerequisite call, then the store and dryRun semantics. It is dense but each sentence carries distinct operational value; only minor tightening is possible.

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 generic destructive dispatcher with 9 parameters and no output schema, the description covers the critical unknowns: scope of stores, read/write permission gating, auth injection, and a safe dryRun preview. Missing only multi-store failure semantics and response-shape expectations, which matter less given the parameterized, open-world nature of the 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 coverage is 78%, so most parameters (body, query, headers, formData, pathParams, maxResponseChars) are already documented structurally. The description adds meaning for store and dryRun — notably that dryRun shows the generated URL/body without sending — but leaves the remaining parameters unaddressed, so the baseline 3 is appropriate.

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?

States a specific verb and resource: executes any Trendyol API operation identified by operationId, on behalf of a chosen store. It distinguishes itself from siblings by naming trendyol_get_operation (for parameter discovery) and trendyol_list_stores (for store names), so an agent can tell it apart without opening another schema.

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 to call trendyol_get_operation first to learn parameters, defines the store argument's three modes (name, empty = default, "*" = all stores for reads only), and states that write operations run only on stores with write permission. Prerequisites and constraints are spelled out rather than implied.

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