mcp-server

get_marketplace_report

Read-onlyIdempotent

Get the validation report for one marketplace: the aggregated errors and warnings that block or degrade its listing, with fix suggestions. Use this to explain why marketplace products fail validation. The errors are SPLIT into two groups (as in the CP's two separate views). Returns {integrationId, errorCount, warningCount, statusCounts:[{status, count}], listingStatusCounts:[{status, count}], dataCheckErrors:[...], channelErrors:[...]}, where each error is {source, field, message, code, level, count, fixSuggestions:[{type, stepType, label}]}. dataCheckErrors = the pre-submission KOONGO DATA CHECK (feed-generation validation, source='export' — the same the wizard summary/preview shows, produced when the feed is generated BEFORE anything reaches the channel). channelErrors = the marketplace's OWN responses AFTER submission (source='adapter'/'api_error' — the integration detail). errorCount/warningCount are the COMBINED totals across both groups. Data-check errors exist only after a generation has run — finish the wizard, or repair_marketplace to (re)generate; export is async, so poll marketplace_status until productsRefreshing AND productsSubmitting are false, then read the report. statusCounts is how many items sit in each koongo processing status (e.g. completed / error / pending); listingStatusCounts the same by channel listing status (e.g. active / rejected / error). level is error|danger(=warning)|info; count is how many products hit that error. fixSuggestions.type is add_category_mapping|fix_settings|rewrite_attribute| exclude_product, and stepType (when set) names the wizard step to open with configure_marketplace_step. This is the marketplace-wide breakdown; for a single product's report use get_marketplace_item_report. marketplace_id is the id from list_marketplaces. project_id is OPTIONAL (inferred for a single-project customer; project_id_required otherwise — then call list_projects).

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": "get_marketplace_report"
  }
}

Input Schema

Name	Required	Description	Default
`project_id`	No
`marketplace_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so safety is covered; the description goes well beyond by disclosing the async export behavior and required polling, the two-view split (dataCheckErrors as pre-submission feed generation vs channelErrors as post-submission adapter responses), and that errorCount/warningCount are combined across both groups — a genuinely non-obvious aggregation detail.

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?

Purpose and the critical precondition lead, and nearly every sentence carries information (no output schema means the inline return-shape enumeration earns its place). It is dense and long, though — the return-shape and field-glossary sentences in the middle could be tightened, and the level/count/fixSuggestions enumeration adds bulk.

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 read-only reporting tool with no output schema and 0% param coverage, the description supplies the return object shape, the meaning of each error field, the enum values for level and fixSuggestions.type, and the cross-tool step (configure_marketplace_step) to act on suggestions. Nothing an agent needs to call it and interpret results is missing.

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 the burden, and it does: marketplace_id is traced to list_marketplaces, and project_id is explained as OPTIONAL/inferred for single-project customers with an explicit fallback to list_projects when project_id_required. That fully compensates for the undocumented schema.

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+resource: 'Get the validation report for one marketplace', then defines scope as aggregated errors/warnings blocking a listing, and explicitly delimits itself against get_marketplace_item_report ('for a single product's report use ...'). An agent can distinguish it from get_ad_report and the item-level sibling without opening any schema.

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?

States the use case ('explain why marketplace products fail validation'), names the alternative for the single-product case, and gives the critical preconditions: data-check errors require a generation to have run, and the agent must poll marketplace_status until productsRefreshing AND productsSubmitting are false. It also routes project_id resolution to list_projects when project_id_required is flagged.

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?