MyDesigns

Update seller info

update_seller_info

DestructiveIdempotent

Change the seller info of one of the seller's stores: who sells there (a person or a business), their legal address and how to reach them. The store's legal pages show it, so fill it only with what the seller tells you: never guess or make up a name, address or VAT number. Only the values given change, but the store keeps seller info only when it is complete, as the app does: when list_stores shows some missing, ask the seller for all of it first, then make one call.

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": {
      "storeId": "<storeId>"
    },
    "name": "update_seller_info"
  }
}

Input Schema

Name	Required	Description
`clear`	No	Fields to remove, any of: dbaName, addressLine2, addressState, phone, vatId, registrationNumber.
`phone`	No	Phone number.
`vatId`	No	VAT number, e.g. DE123456789.
`dbaName`	No	The name a business trades under, when it is not its legal name.
`storeId`	Yes	The store id from list_stores.
`legalName`	No	The person's full legal name, or the business's legal name.
`addressZip`	No	ZIP or postal code.
`legalEmail`	No	Email for legal notices, shown on the legal pages.
`sellerType`	No	individual when a person sells in their own name, business when a company does. Needed the first time; ask the seller.
`addressCity`	No	City.
`addressLine1`	No	Street and number.
`addressLine2`	No	Second address line: suite, floor or unit.
`addressState`	No	State or province, e.g. IL; needed in the United States and Canada.
`addressCountry`	No	Two-letter country code, e.g. US or DE.
`registrationNumber`	No	A business's company registration number, e.g. HRB 12345.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 4, 2026

changedInput schema / properties / vatId / description

Previous value: -"VAT or tax ID, e.g. DE123456789."New value: +"VAT number, e.g. DE123456789."

First observedNov 4, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Goes well beyond the annotations: explains that only supplied values change (partial-update semantics behind idempotentHint), that the data is publicly rendered on the store's legal pages, and that the store only retains seller info when it is complete, which justifies the destructive/overwrite behavior. The practical consequence — collect everything before calling — is stated outright.

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, then constraints, then workflow; three sentences with no padding. The final sentence is a run-on that chains partial-update semantics, the completeness rule and the list_stores workflow together, costing a little readability.

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 15-parameter mutation tool whose annotations flag destructive and open-world behavior, the description covers purpose, data-integrity rules and the multi-step workflow. Return values are not described, and there is no output schema, so an agent does not know what a successful call yields.

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

Parameters3/5

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

Schema coverage is 100% and every field already carries a description, including examples for vatId, addressState and addressCountry, so the description does not need to restate them. It adds only light framing by grouping the fields into identity, address and contact. Baseline 3 is appropriate.

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?

States a specific verb (change) and resource (seller info of a store), then enumerates the three concerns the fields cover: who sells there, legal address, contact details. An agent can distinguish this from update_store, which handles general store settings, because the scope here is explicitly limited to seller/legal identity data.

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?

Gives a concrete precondition and workflow: check list_stores, and when seller info is missing ask the seller for all of it, then make one call. It also sets an explicit constraint (never guess a name, address or VAT number). It stops short of naming update_store as the tool for non-seller store settings, so sibling routing is only implicit.

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

All MyDesigns 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.

Resources

Need Help?