Korea E-commerce Integrated Channel MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct resource and action: product lifecycle verbs (publish, update, stop, resume, delete, get), profile operations (list, preview), and channel introspection (capabilities, health). No two tools appear to perform the same function, so an agent can easily select the correct one.
Naming Consistency4/5
The naming pattern is mostly consistent: product_<verb> for product operations, profile_<verb> for profile operations, and channel_<noun> for channel metadata. The only minor deviation is channel_capabilities and channel_health using nouns while others use verbs, but the pattern remains predictable and readable.
Tool Count5/5
With 11 tools, the set is well-scoped for an e-commerce channel integration server. Each tool addresses a clear need without unnecessary bloat, covering product management, profile handling, and channel introspection in a balanced way.
Completeness5/5
The tool surface covers the full product lifecycle across channels: publish, update, stop, resume, delete, and get, plus profile management and operation status tracking. There are no obvious dead ends; all core workflows are supported, and the included channel capabilities/health tools round out the domain.
Average 3.7/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the preview/resume distinction, which implies different side effects (preview likely safe, resume mutates). However, it doesn't disclose the need for approval tokens, idempotency keys, or the cross-channel impact in detail. Annotations already indicate a non-read-only operation, but openWorldHint=true calls for more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the action, no filler. Every word adds value; it's concise and easily parsed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (nested command, two-phase approval, multi-channel, safety assertions), but the description provides only a high-level purpose. It doesn't explain the preview/execute workflow, how output schema reflects status, or the need for idempotency and approval. Sibling names and schema fields exist, but description fails to integrate them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 compensate. It vaguely hints at 'selected channel' and the preview/resume modes mapping to 'channels' and 'confirm'/'dry_run', but doesn't explain required fields like sku, idempotency_key, or approval_token, nor the safety assertions.
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?
The description uses a specific verb ('Preview or resume') and names the resource ('a product') and scope ('every selected channel'), clearly distinguishing it from sibling tools like product_stop or product_publish. The title reinforces the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like product_publish or product_update. It implies the resume use case but doesn't mention prerequisites, exclusions, or the difference between preview and execute modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe, non-mutating nature is clear. The description adds minimal context about reporting checks and inspecting a field, but does not elaborate on behavioral details like authentication or rate limits. Since annotations cover the main safety profile, the addition is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or repetition. It is front-loaded, stating the action and resource immediately, making it highly concise and efficient.
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?
The tool is simple with no parameters and has an output schema to document return values. However, the description is vague about what 'configuration and connector-supported checks' entail and what 'network_checked' means. While the output schema helps, the description leaves enough ambiguity that the tool's exact behavior is not fully clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description need not explain any. The baseline for 0 params is 4, and the description adds nothing unnecessary about parameters, which is appropriate.
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?
The description uses the specific verb 'Report' and identifies the resource as 'configuration and connector-supported checks' while mentioning 'network_checked'. This conveys the tool's basic purpose but leaves the meaning of 'network_checked' ambiguous. It implicitly distinguishes from siblings like channel_capabilities by focusing on health checks, but not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as channel_capabilities or product_get. The description does not mention scenarios, prerequisites, or exclusions, leaving the agent without clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false. The description adds the crucial 'Preview or update' dichotomy and 'in parallel' execution behavior. It does not contradict annotations, so a score of 4 is warranted for adding behavioral context beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It front-loads the verb and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex multi-step operation (preview/update across channels) with output schema, but the description lacks essential context such as the need for idempotency keys, approval tokens, expectations on channel mapping, or the safe preview-first workflow. It is too terse to fully orient an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The single-sentence description gives no parameter guidance, while the schema has a complex command object with many fields including idempotency_key, approval_token, channels, and payloads. The description adds no semantics for these parameters, failing to compensate for the low schema coverage.
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?
The description uses a specific verb phrase 'Preview or update' and names the resource 'a mapped product' and scope 'across selected channels in parallel'. This clearly distinguishes it from siblings like product_get (retrieval) and product_delete (removal).
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?
No explicit when-to-use or alternative guidance is provided. The description implies usage for updating mapped products but does not mention when to prefer this over product_publish or product_stop, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the key behavioral trait that no external seller API is called, giving context beyond the annotations and confirming it is a safe, local operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, but the description is too minimal for a tool with a complex product input. It does not explain what a 'reviewed profile' is, how the product data is used, or when to use this tool relative to the sibling product operations. The description lacks sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides no explanation of the two parameters (profile_id and product). Neither the description nor the schema describe these parameters, leaving the agent without guidance on how to construct the input.
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?
The description clearly states it renders a reviewed profile without calling an external seller API. The verb 'render' and resource 'profile' make the action specific, and it distinguishes this from sibling tools like product_publish or profile_list.
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?
The description implies usage for local preview by noting it does not call an external seller API, but it does not explicitly state when to use this tool versus alternatives like product_publish or product_update. The 'when-to-use' guidance is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnly=false. The description adds the 'Preview' option, indicating a non-destructive dry-run capability. But it does not explain the need for approval tokens, idempotency keys, or the permanence of the stop action beyond what annotations imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose ('Preview or stop a product') and the scope ('every selected channel'). No wasted words; it earns its place.
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?
The schema provides rich detail for parameters and an output schema covers return values. The description is minimal but sufficient to convey the core action, though it does not mention the safety workflow (preview before execute) or approval requirements. Given the available annotations and schema, this is adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description text provides no parameter-level details. While the schema has titles like 'Confirm' and 'Dry Run' that align with the description's 'Preview' phrase, the description does not compensate for the lack of parameter explanations, especially for security-related fields like approval_token and expected_external_ids.
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?
The description uses a specific verb ('stop') and resource ('product') with clear scope ('every selected channel'), and also mentions 'Preview' to indicate a dual mode. This clearly distinguishes it from siblings like product_resume and product_delete.
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?
The description implies usage: stop a product on selected channels, and mentions 'Preview' as a safer option. However, it does not explicitly state when to use this tool versus alternatives like product_delete or product_resume, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey destructiveHint=true, readOnlyHint=false, so the description doesn't need to repeat those. It adds value by distinguishing 'Preview' (safe) from 'permanently delete' (destructive), giving a useful behavioral nuance. However, it does not disclose additional details like approval_token or confirm_delete requirements, which would have strengthened transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly written sentence that conveys the core purpose without any filler or redundant details. It is concise and front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and annotations, the tool's input command is complex with many nested fields (idempotency_key, approval_token, confirm_delete, expected_external_ids) and involves a safety-critical flow (preview vs execute). The description is far too minimal to guide an agent through correct usage, especially the distinction between preview mode and permanent deletion with confirmation requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 compensate for parameter meaning. It only hints at 'mapped product' (sku) and 'selected channels' (channels), but completely ignores required fields like idempotency_key and the confirm/dry_run/confirm_delete mechanism that are essential for proper invocation. This leaves the agent under-informed about the command structure.
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?
The description clearly states the tool's function: 'Preview or permanently delete a mapped product across selected channels.' It specifies the action (delete), the resource (mapped product), and the scope (selected channels), making it distinct from sibling tools like product_stop or product_update.
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?
The description implies usage for deletion or preview of deletion, but it does not explicitly contrast with alternatives such as product_stop or provide when-not-to-use guidance. It lacks clear exclusions or alternative tool references, so an agent gets only an implied context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds non-obvious behavioral context by stating that the read includes 'per-channel partial failures,' which informs the agent about a potential and important aspect of the response. This goes beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, efficiently front-loaded with the core action 'Read a persisted operation' followed by a valuable detail. Every word contributes to understanding, with no filler or repetition.
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?
Given the tool has only one parameter, a straightforward read operation, and an output schema exists, the description covers the core functionality adequately. It mentions the key detail of partial failures which is important for a fan-out operation. It could arguably include more about the job_id format or partial failure semantics, but these are partially covered by the output schema, so it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter 'job_id' with no description, and the schema coverage is 0%. The tool description does not explicitly explain what job_id is or how to obtain it, though the context of 'operation' implies it is an operation ID. This is minimal compensation, so the description adds little meaning beyond the parameter name itself.
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?
The description clearly states the tool's function: 'Read a persisted operation' with a specific verb and resource. It also adds a distinguishing detail ('including per-channel partial failures') that differentiates it from sibling tools like product_get or profile_list, which likely deal with other resources.
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?
The description implies usage: you use this to read a persisted operation. However, it does not explicitly state when to use it versus alternatives, nor does it mention any exclusions or prerequisites. The guidance is implicit based on the resource type, but there are no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description complements annotations by disclosing parallel execution and the preview vs. create modes, which are not captured by readOnlyHint, openWorldHint, etc. It does not detail failure handling or approval requirements, but the annotations already cover the basic safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the core functionality. It is front-loaded and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with many parameters (idempotency_key, approval_token, payloads, dry_run) and an output schema, but the description is minimal. It fails to explain the preview/execute workflow, how channels are chosen, what 'in parallel' means for error handling, or what the response will contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate for the complex command object. It hints at 'preview or create' (matching the confirm parameter) but provides no clarification for idempotency_key, approval_token, payloads, or channel selection semantics.
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?
The description clearly states it 'previews or creates one master product across all selected channels in parallel,' identifying the exact action and resource. It distinguishes the tool from siblings like product_update or product_stop by focusing on multi-channel publishing.
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?
The description provides clear context that this is for publishing a product across multiple channels, with a preview/execute dichotomy. However, it does not explicitly mention when to avoid this tool or recommend alternatives like product_update for edits, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the specific return scope (connectors, config state, operations) but does not disclose additional behaviors such as output size or potential prerequisites. For a simple no-parameter read-only tool, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb 'Show' and enumerates the key output categories. Every word contributes value, with no redundancy or filler.
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?
The tool is simple (no parameters, read-only) and an output schema exists, so the description does not need to explain return values in detail. It captures the essential purpose and distinguishes the tool's scope. The only minor gap is the lack of explicit differentiation from channel_health, but that is not required for a basic inventory query.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds conceptual meaning by explaining what the tool returns, though no parameter details are necessary. It appropriately does not attempt to describe nonexistent parameters.
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?
The description uses a specific verb ('Show') with a clear resource ('installed connectors, configuration state, and supported operations'), which unambiguously states the tool's function. This distinguishes it from sibling tools like channel_health or the product/profile tools.
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?
The description implies usage for inspecting channel capabilities but provides no explicit when-to-use guidance or alternatives. Given the sibling channel_health, the description does not clarify when to choose one over the other, making the guidance merely implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds minimal context by noting the profiles are 'local' and can transform a master product, but does not disclose behaviors like sorting, filtering, or the meaning of 'reviewed'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the action and purpose. Every word earns its place with no redundancy or fluff.
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 simple, parameterless, read-only list tool with an output schema present, the description is largely sufficient. It explains what is listed and why, but could optionally clarify the 'reviewed' qualifier from the title or how 'local' differs from other scopes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no parameter documentation is needed. The baseline for 0 params is 4, and the description doesn't add or need parameter-related detail.
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?
The description uses a specific verb ('List') with a clearly defined resource ('local payload profiles') and states their purpose ('turn one master product into channel bodies'). This distinguishes it from sibling tools like profile_preview, which previews rather than lists.
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?
The description implies when to use the tool (when you need to see available profiles) but provides no explicit guidance on when not to use it or how it compares to alternatives like profile_preview. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the nuance of returning the 'canonical' product and per-channel identifiers, providing data-context beyond the safety profile. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that starts with the verb 'Read' and contains no filler.
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 simple read tool with a clear output schema and robust safety annotations, the description sufficiently states the tool's function. It doesn't explicitly reference the sku parameter, but the schema and title fill that gap, so completeness is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's single parameter 'sku' has no description (0% coverage). The description fails to mention the parameter at all, leaving the agent to infer that 'sku' identifies the product. With low coverage, the description should compensate but does not.
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?
The description uses the specific verb 'Read' and identifies the resource as 'canonical product' with 'per-channel external identifiers', clearly distinguishing it from mutation siblings like product_update, product_stop, product_publish, product_resume, and product_delete.
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?
While the description doesn't explicitly name alternatives, its read-only nature and the presence of mutation-oriented sibling tools make the usage context clear. It doesn't provide exclusions or when-not guidance, but the role as the getter is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

korea-ecommerce-integrated-channel-mcp MCP server

Copy to your README.md:

[![korea-ecommerce-integrated-channel-mcp MCP server](https://glama.ai/mcp/servers/rlaalsdn4564/korea-ecommerce-integrated-channel-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rlaalsdn4564/korea-ecommerce-integrated-channel-mcp)

Score Badge

Copy to your README.md:

[![korea-ecommerce-integrated-channel-mcp MCP server](https://glama.ai/mcp/servers/rlaalsdn4564/korea-ecommerce-integrated-channel-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rlaalsdn4564/korea-ecommerce-integrated-channel-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rlaalsdn4564/korea-ecommerce-integrated-channel-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server