3Dsellers

create-mapping-rule

Create a mapping rule and return its id. A mapping rule computes what a channel field is sent, instead of copying a product column across unchanged: a percentage off the price, a fallback chain across UPC/EAN/ISBN, a conditional literal. A field mapping points at one by ruleId on apply-product-template-mappings, and rules are company-wide, so one rule can back the same field on every template.

Nothing changes on any listing from this call: wire the returned id into templates with apply-product-template-mappings ({ fieldName: "price", scope: "common", ruleId }), then republish. Check the arithmetic first with preview-mapping-rule.

conditions is an array of branches evaluated in order, each { conditions, successful_output, failed_output }. The inner conditions is an array of AND-groups that are ORed together. An output is { template, filters, type, round, charm_price }: template is a "{{property}}" string, type: "number" keeps a numeric field numeric, and filters transform the value.

Worked example — send price 5% under catalog price: [{"conditions":[[{"type":"number","option":"has value","property":"price","value":""}]],"successful_output":{"template":"{{price}}","type":"number","filters":[{"type":"math","option":"calculate","attribute":"price","additional_settings":{"items":[{"math_option":"multiply","value":0.95}],"round":"","charm_price":false}}]},"failed_output":null}]

math_option is multiply, divide, add or subtract and items chain in order; round is "", "round up", "round down" or "full".

charm_price exists at BOTH levels and they do different things. On the output (sibling of template/filters) it rounds UP to end in .99, so 37.43 becomes 37.99 — that is the one you usually want. Inside a filter's additional_settings it only shaves a cent off a value that is already a whole number, so 38 becomes 37.99 but 37.43 is left alone.

Authenticated via bearer token.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "conditions": "<conditions>"
    },
    "name": "create-mapping-rule"
  }
}

Input Schema

Name	Required	Description
`name`	Yes	Rule name
`conditions`	Yes	Array of rule branches — see the worked example above
`description`	No	Free-text description
`failedOutput`	No	Legacy top-level fallback output
`successfulOutput`	No	Legacy top-level output. Only for the older single-branch format; current rules keep outputs inside the branches.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations declare a non-read-only, non-destructive, closed-world create, and the description adds real context beyond that: nothing changes on any listing from this call alone, the id must be wired into a template and republished before it has effect, and rules are company-wide rather than per-template. The bearer-token note is boilerplate but harmless.

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?

Front-loaded with purpose and return value, then effect, then the conditions grammar, then a worked example — a sound order. It runs long, and the four-sentence charm_price discussion plus the trailing 'Authenticated via bearer token' line are more than strictly needed, but the depth is justified by the empty `items: {}` schema.

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?

For a deeply nested, enum-free, output-schema-less create tool, the description covers everything an agent needs: return value, downstream wiring, the full branch/output grammar, a validated worked example, and the one flag that reliably causes mistakes.

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 coverage is 100%, so baseline would be 3, but the description goes far beyond it — the schema leaves `conditions.items` as an empty object, and the description supplies the branch shape { conditions, successful_output, failed_output }, the AND-groups-ORed semantics, the output fields (template/filters/type/round/charm_price), the math_option vocabulary, the round values, and the genuinely non-obvious dual meaning of charm_price.

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?

Opens with a specific verb and resource plus the return value ('Create a mapping rule and return its id'), then defines what a mapping rule actually computes versus a plain column copy. That definition cleanly separates it from update-mapping-rule, get-mapping-rule, preview-mapping-rule and the template siblings.

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?

Gives explicit when-to-use routing: use preview-mapping-rule to check the arithmetic first, then apply-product-template-mappings to wire the returned id into a field, then republish. It also names the exact invocation shape ({ fieldName: "price", scope: "common", ruleId }) and states the scope fact that rules are company-wide and reusable across templates.

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

All 3Dsellers tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.