mcp-server

submit_marketplace_items

Destructive

MARKETPLACE items: submit — send the chosen items to the LIVE marketplace, also in MANUAL product mode (one item_id is the safe test). Use this when the user asks to publish specific listings. Needs confirm:true after the user agrees. Target item_ids or all_items:true.

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": {
      "marketplace_id": "<marketplace_id>"
    },
    "name": "submit_marketplace_items"
  }
}

Input Schema

Name	Required	Description
`confirm`	No	true only after the user approved; without it the call returns confirm_required and nothing runs.
`item_ids`	No	itemId values (from list_marketplace_items) to act on. Use this OR all_items.
`all_items`	No	Apply to every item of the marketplace. Use this OR item_ids.
`project_id`	No
`marketplace_id`	Yes	integrationId of the marketplace (from list_marketplaces).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 3, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already flag destructive/openWorld, but the description adds genuinely new behavioral context: the confirm:true gate returning confirm_required, that items land on the LIVE marketplace, and that MANUAL product mode permits a single-item safe test. What is missing is any statement of what happens to already-submitted items or whether submission is reversible.

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?

Three short sentences, front-loaded with the resource and action, with the confirm requirement placed early. The ALL-CAPS emphasis ('LIVE', 'MANUAL', 'MARKETPLACE') is a little noisy but does not waste space.

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

Completeness3/5

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

For a destructive, open-world tool with five parameters and no output schema, the description covers the publish intent, confirmation gate and target selection adequately. It leaves project_id undefined and says nothing about the outcome state of submitted items or partial-failure behavior.

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?

With 80% schema coverage the schema already documents confirm, item_ids, all_items and marketplace_id, and the description mostly restates the 'item_ids OR all_items' exclusivity. The one value-add is the hint that a single item_id functions as a low-risk test; project_id remains unexplained in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'send the chosen items to the LIVE marketplace', making the publish action distinguishable from cleanup and force-insert siblings. It does not explicitly contrast with submit_all_marketplace_items, so the boundary with that near-namesake must be inferred from 'chosen items'.

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

Usage Guidelines3/5

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

'Use this when the user asks to publish specific listings' gives an explicit trigger, and 'one item_id is the safe test' gives a safe-usage pattern. However, it never names the alternative tools (submit_all_marketplace_items, force_insert_marketplace_items, clean_marketplace_items), so an agent must work out exclusions itself.

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

All mcp-server 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?