나만을 위한 AI 쇼핑 MCP — 상품을 자연어로 검색·비교·추천해 사용자의 효과적인 쇼핑을 돕습니다.
슈퍼쇼핑 카테고리 시세 분석 — 가격 분포·최저가몰·대안.
언제: 사용자가 시세/적정가를 물을 때("그래픽카드 요즘 얼마", "노트북 가격대"). category는 이름(예: '노트북') 또는 ID. 반환: 가격 통계(최저/중앙/최고·분포)·최저가 쇼핑몰·대안 상품.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | ||
| attributes | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds valuable context about the return data (price statistics, lowest price mall, alternative products), enhancing transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single line for purpose and a single line for usage/output. No unnecessary words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which handles return value details), the description adequately covers the tool's purpose, when to use, and what it returns. It could mention potential errors or edge cases but is generally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only adds meaning for the 'category' parameter (name or ID), but the 'attributes' parameter is not mentioned. This incomplete coverage results in a score of 2.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes Super Shopping category market prices, including price distribution, lowest price mall, and alternatives. It uses specific verbs and resources (analyze market) and distinguishes from sibling tools like compare_products and search_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (when users ask about market prices or fair prices) with concrete examples. However, it does not specify when not to use it or mention alternative tools, so it scores 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
슈퍼쇼핑 상품 여러 개(2~5개)의 스펙·가격 비교 매트릭스 + 한 줄 결론.
언제: 사용자가 후보 여러 개를 견주려 할 때("이 중에 뭐가 나아?"). product_ids는 search 결과에서. 반환: {attributes: 공통 키, matrix: 상품별 값/가격, verdict: 한국어 결론}.
| Name | Required | Description | Default |
|---|---|---|---|
| product_ids | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readonly, idempotent, non-destructive. The description adds concrete behavior: returns a matrix with attributes, values, prices, and a Korean verdict, and limits input to 2-5 products. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a usage hint, all front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema (context signal), the description adequately covers input, output structure, and usage context. Could mention return format more explicitly, but sufficient for a comparison tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (product_ids array) with 0% schema description coverage. Description adds that IDs come from search results, which provides some context, but lacks detail on array size constraints or format. Baseline for coverage 0% is low; description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it compares 2-5 products and returns a spec/price matrix with a verdict. This distinguishes it from siblings like search_products (searching) or get_product_detail (single product).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance ('when user wants to compare multiple candidates') and notes product_ids come from search results. Does not explicitly mention when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
슈퍼쇼핑 상품의 전체 상세 — 스펙·쇼핑몰별 가격(offers)·신품/중고 교차비교.
언제: 사용자가 한 상품을 깊이 보거나 구매 직전일 때. (product_id는 search/recommend 결과에서 얻는다) 반환: 전체 속성 + offers(쇼핑몰별 buy_url) + comparison_url + other_sources(같은 모델의 다른 소스 신품↔중고 가격 스프레드) + affiliate_disclosure(있으면 고지). → other_sources로 "같은 모델 중고는 얼마" 같은 가격차를 안내하면 좋다.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, open-world, idempotent, and non-destructive. Description adds return details (attributes, offers with buy URLs, comparison URL, other sources for cross-market new/used price spreads, affiliate disclosure) without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: starts with purpose and key content, then '언제:' for usage context, and '반환:' for return details. Every sentence adds value; no redundancy. Length is appropriate for the detail provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required param, no nested objects, has output schema), the description covers when to use, input source, return structure, and actionable guidance (e.g., using other_sources for price comparison). It fully equips an agent to decide and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (product_id) with 0% schema coverage. The description provides context that product_id comes from search/recommend results, but doesn't specify format or type beyond the schema's string type. This is sufficient for a single well-understood parameter, though more explicit definition would be ideal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed product info including specs, prices from shopping malls (offers), and cross-comparison of new/used items. It distinguishes from siblings like search_products or compare_products by focusing on a single product deep dive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: when a user wants to see a product in depth or is about to purchase. Also notes product_id comes from search/recommend results, linking to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
슈퍼쇼핑 상품의 대표 이미지를 실제 이미지(렌더 가능)로 반환.
언제: 사용자가 상품 사진을 보고 싶어할 때("이 코트 보여줘"). 검색/추천 결과의 thumbnail은 URL(텍스트)이라 화면에 안 뜨므로, 시각 확인이 필요하면 이 툴로 이미지 자체를 가져온다. 반환: 이미지 콘텐츠(여러 개를 한 번에 보여주지 말고 관심 상품 위주로 호출).
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive. The description adds value by specifying the return is actual image content (not URL) and advising usage pattern. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs with essential info front-loaded. Each sentence adds value, though could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description adequately explains return type (renderable image) and usage context. Slightly lacking return format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter product_id, which is self-explanatory by name. Schema coverage is 0%, but the description does not add format or constraint details beyond the name. Minimum viable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the actual renderable image for a SuperShopping product, distinguishing it from sibling tools like search_products that provide URL thumbnails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: when user wants to see product photos. Offers practical advice to focus on interested products rather than showing multiple simultaneously. Lacks explicit when-not or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
슈퍼쇼핑에서 선택한 상품의 구매로 연결 — 최저가 쇼핑몰의 구매 링크와 가격·고지를 반환.
언제: 사용자가 구매 의사를 보일 때("이거 살래", "구매하기"). 실제 결제는 판매처 페이지에서 일어난다. 반환: {payload: {merchant, buy_url(제휴 변환됨), price, ...}, affiliate_disclosure?, next_actions}. → buy_url을 명확한 구매 링크로 제시하고, affiliate_disclosure가 있으면 반드시 고지하라. 중고(used)는 개인 직거래이므로 안전결제/실물확인을 안내하라.
| Name | Required | Description | Default |
|---|---|---|---|
| quantity | No | ||
| product_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate the tool is not read-only and open-world; the description adds that actual payment occurs on the merchant page, explains the return structure (buy_url, affiliate disclosure), and gives special guidance for used items. This provides useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate sections for purpose, usage condition, return value, and additional notes. It is concise and front-loaded with the primary action, though slightly dense due to multiple details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema is implied and annotations provide some hints, the description covers the main concerns: when to use, what is returned, and a special case (used items). However, it lacks error handling or prerequisites like having a selected product, and the demo nature is noted only in the title.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (product_id, quantity) with 0% description coverage. The description does not explain these parameters or their defaults; it only implies product_id contextually. Quantity is not mentioned, leaving agents to infer its meaning from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool initiates checkout for a selected product in Super Shopping and returns a purchase link, price, and affiliate disclosure. It distinguishes itself from sibling tools (search, compare, recommend) which handle different stages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use the tool when the user shows purchase intent ('이거 살래', '구매하기'), providing clear usage context. It does not mention when not to use or alternatives, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
슈퍼쇼핑에서 어울리는 코디를 추천 (씨앗 상품 또는 의도 기반).
언제: "이 코트에 어울리는 코디", "가을 데이트룩 코디" 처럼 한 벌 구성을 원할 때. 인자: product_id(씨앗 아이템, 선택), intent(의도/무드, 선택), budget(전체 예산 상한, 선택). 둘 중 하나는 필요. 반환: {seed, items:[{slot, title, min_price, reason, buy_url, thumbnail, source}], styling_reason, affiliate_disclosure?}. → 각 아이템을 buy_url 링크와 함께 제시하고, 사진은 get_product_image로 보여줘라.
| Name | Required | Description | Default |
|---|---|---|---|
| budget | No | ||
| intent | No | ||
| product_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint, and openWorldHint. The description adds context about the return structure (seed, items with slots, styling_reason, affiliate_disclosure) and advises using get_product_image for photos. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three short paragraphs. The first sentence states the purpose, the second provides usage guidelines, the third describes parameters and returns. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and the presence of output schema and good annotations, the description covers essential aspects: input requirements, output structure, and a practical note about using get_product_image. It is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description explains each parameter: product_id (seed item, optional), intent (intent/mood, optional), budget (total budget upper limit, optional), and the constraint that at least one of product_id or intent is required. It does not specify possible intent values or format, but the explanation adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: recommending suitable outfit coordination based on seed product or intent. It distinguishes from sibling tools like 'recommend_products' by focusing on full outfit compositions (한 벌 구성). The specific verb 'recommend' and resource 'outfit coordination' are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use scenarios with examples ('이 코트에 어울리는 코디', '가을 데이트룩 코디') and states that at least one of product_id or intent is needed. However, it does not explicitly mention when not to use this tool or suggest alternatives like 'recommend_products' for single items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
슈퍼쇼핑에서 의도·예산 기반 상품 추천 + 추천 근거.
언제: 사용자가 구체적 검색어 없이 용도/취향/예산만 말할 때("겨울 데이트룩 추천", "50만원대 가성비 노트북"). 인자: intent(용도/취향), budget(예산 상한), must_have(필수 조건). 반환: {recommendations: [{title, min_price, reason, buy_url, thumbnail, source}], affiliate_disclosure?}. → 각 추천을 buy_url 링크와 함께 제시하고, 사진은 get_product_image로 보여줘라.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| budget | No | ||
| intent | Yes | ||
| must_have | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, confirming safe read operation. The description adds behavioral details: returns recommendations with rationale, field structure, and suggests using get_product_image for photos. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with bullet points and clear sections. It is concise but includes all necessary information. Slightly verbose due to Korean and English mix, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations provide safety profile, the description is complete. It covers usage, parameter meanings, and return format. Even includes guidance on using get_product_image for images.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It explains intent, budget, and must_have with meanings in Korean, but omits the limit parameter (default 5). Also does not clarify nullability for budget and must_have. Partial coverage leaves a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it recommends products based on intent and budget, and distinguishes from sibling tools like search_products (specific query) and recommend_outfit (likely fashion-focused). The verb 'recommend' and resource 'products' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: when user provides only purpose/taste/budget without specific search terms. Implies not for exact product queries, suggesting alternatives like search_products.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
자연어로 신품·중고 통합 상품 검색 (슈퍼쇼핑의 기본 진입점).
언제: 사용자가 특정 상품을 찾을 때. 예) "남성 패딩 20만원 이하", "중고 RTX 4070", "27인치 게이밍 모니터". 자동 처리: 도메인(패션/전자)·성별·가격대·속성을 질의에서 추출해 필터링. 반환: {items: [{title, min_price, key_specs, thumbnail, buy_url, source, condition, ...}], total}. → 결과 제시 시 각 buy_url을 링크로 함께 보여줘라. 사진은 get_product_image로 렌더. 추천만 원하거나 검색어가 모호하면 recommend_products를 써라.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| category | No | ||
| max_price | No | ||
| min_price | No | ||
| attributes | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint false. The description adds behavioral context: automatic extraction of domain, gender, price, attributes; return structure; and instruction to use get_product_image for images. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, front-loads purpose and usage, and includes examples. It covers multiple aspects without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, 0% schema coverage, and output schema present, the description provides purpose, usage, and return format. However, it lacks detailed explanation of explicit parameters like category and attributes beyond automatic extraction.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description should compensate. It mentions query is natural language and limit has default 10, but does not explain category, max_price, min_price, or attributes. Automatic extraction is mentioned, but explicit parameter roles are unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies it is a natural language search tool for new and used products, and it is the basic entry point for Super Shopping. Examples illustrate usage, and it distinguishes from recommend_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (user looking for specific product) and when not to (ambiguous query or recommendations wanted, pointing to recommend_products). It also notes automatic extraction of filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
AI commerce for Shopify: product search, comparison, recommendations, and checkout via MCP.
Hosted MCP for e-commerce: live product catalog, stock, and pricing for AI agents.
Multi-tenant MCP gateway for AI commerce. One connection, every store.
Multi-tenant MCP gateway for AI commerce. One connection, every store.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: market analysis, product comparison, detail retrieval, image fetching, checkout initiation, outfit recommendation, general recommendation, and search. Descriptions and usage contexts disambiguate effectively.
All tool names follow a consistent verb_noun pattern (e.g., analyze_market, compare_products) using lowercase with underscores, making them predictable and easy to differentiate.
With 8 tools covering search, recommendation, comparison, details, images, market analysis, and checkout, the count is well-scoped for a comprehensive shopping assistant without being overwhelming.
The tool surface covers the main shopping workflow—search, recommend, compare, view details, images, market analysis, and checkout. Minor gaps like category listing or user-specific features are absent but not critical for the core purpose.