mcp-server

get_order_connection

Read-onlyIdempotent

Full detail of ONE standalone order connection, including its Orders Config form. Use this to read an order connection's settings before changing them. Returns {connectionId, name, channelCode, channelLabel, channelApiCode, status, orderStatus, orderSyncLevel, authType, connected, expired, hasCredentials, authMessage, lastSyncStatus, lastSyncAt, lastSyncMessage, ordersThisMonth, orderConfigFields:[{code, label, description, type, required, options, optionsSource, value, defaultValue, adminOnly, locked}]}. A field with locked:true is not included in this Koongo account and cannot be set; options may be null for a field whose choices are only known after the connection is authenticated. Use orderConfigFields to build a configure_order_connection call. connection_id is from get_order_overview. ONLY standalone order connections (from get_order_overview): a connectionId taken from list_orders for a marketplace integration answers 404 here; that is expected, not a broken connection. 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": {
      "connection_id": "<connection_id>"
    },
    "name": "get_order_connection"
  }
}

Input Schema

Name	Required	Description	Default
`project_id`	No
`connection_id`	Yes	connectionId of the order connection (from get_order_overview).

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 readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description still adds real behavioral content beyond that: locked:true fields are unavailable in this Koongo account and cannot be set, options may be null until authentication, and 404 on a marketplace-integration id is expected rather than a broken connection.

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-loads purpose, then usage, then the return shape, so an agent can stop early if it only needs the purpose. It is dense but every clause carries information, though the final sentence chains several parentheticals (404 case, project_id optional, project_id_required) that could be split for readability.

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?

There is no output schema, and the description fully enumerates the returned fields including the nested orderConfigFields shape and its per-field flags. Combined with the id-provenance and error-case guidance, nothing an agent needs to invoke and interpret this call 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 coverage is only 50% (project_id has no schema description), but the description compensates: it names the exact source of connection_id (get_order_overview) and explains project_id's optionality plus the project_id_required fallback to list_projects. That is meaning well beyond the bare integer types in the 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?

States a specific verb and resource — 'Full detail of ONE standalone order connection, including its Orders Config form' — with the scope narrowed to a single standalone connection. It explicitly distinguishes itself from get_order_overview (source of the id) and warns that ids from list_orders for marketplace integrations return 404, so an agent can tell it apart from siblings without reading schemas.

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 ('read a connection's settings before changing them'), a downstream consumer ('use orderConfigFields to build a configure_order_connection call'), and the correct id source ('connection_id is from get_order_overview'). It also covers the project_id fallback path ('project_id_required otherwise — then call list_projects') and names the exclusion case that returns 404.

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?