mcp-server

test_marketplace_connection

Idempotent

Verify that a marketplace's saved connection still works — runs a live connectivity/auth check against the channel right now. Each marketplace owns exactly ONE connection (never shared), so no separate handle is needed: the marketplace_id IS the connection. Use this when a marketplace looks connected but items fail, or after credentials/OAuth may have expired. Returns {integrationId, status ('ok' | 'error' | 'not_connected'), message}. 'not_connected' means the connection step was never completed; to move a connection to a different channel there is no transfer — clone the marketplace with clone_marketplace. Never returns secrets. This does not change any settings. Fixing or (re)establishing a connection (credentials / OAuth) is done by the USER in the browser / Koongo UI, never via MCP: on 'error' / 'not_connected' route the user there, do not retry configure_marketplace_step to set credentials. marketplace_id is from list_marketplaces. project_id is OPTIONAL (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": "test_marketplace_connection"
  }
}

Input Schema

Name	Required	Description	Default
`project_id`	No
`marketplace_id`	Yes	integrationId of the marketplace (from list_marketplaces).

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 1, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Adds substantial behavior beyond annotations: it is a live network/auth call right now, returns {integrationId, status, message} with the meaning of each status value, never returns secrets, and does not change settings. With readOnlyHint=false and openWorldHint=true already declared, 'does not change any settings' is a useful clarification rather than a contradiction, though the tension with readOnlyHint=false could have been spelled out more explicitly (why it is not read-only).

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 the action and trigger, then return shape, then remediation rules. It is on the long side and some clauses (no transfer / clone, secrets) could be tightened, but each sentence carries operational information an agent needs.

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 two-param diagnostic tool with no output schema, the description covers return shape, status vocabulary, secret handling, mutation scope, and error remediation routing. Nothing an agent needs to call it correctly or interpret the result 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?

Compensates fully for the 50% schema description coverage: marketplace_id is documented as coming from list_marketplaces and as being the connection handle itself (no separate handle needed), and the undocumented project_id is explained as OPTIONAL with the project_id_required fallback to list_projects. That is conditional-requirement semantics the schema does not convey.

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 and resource: 'Verify that a marketplace's saved connection still works — runs a live connectivity/auth check against the channel right now.' It also distinguishes the object of the check (marketplace connection) from the ad/order connection siblings by naming the domain and the one-connection-per-marketplace model.

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 triggers ('when a marketplace looks connected but items fail, or after credentials/OAuth may have expired') and explicit non-usage: do not retry configure_marketplace_step to set credentials, route the user to the UI for fixes. It also names clone_marketplace as the only path for moving a connection, so the alternative is unambiguous.

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?