ec-storefront
Server Details
JPYC (JPY stablecoin) EC platform MCP: product search, x402 gasless checkout, order status.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 8 of 8 tools scored.
Each tool serves a distinct purpose: order status, product details, shop details, listing products in a shop, listing all shops, checkout initiation, product search, and payment submission. No two tools have overlapping functionality.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., get_product, list_shops, quote_checkout). The verbs are appropriate (get, list, search, quote, submit) and nouns are clear.
8 tools cover the core user journey of browsing shops/products, searching, and completing a purchase. Slightly above the typical minimal set but still well-scoped; no tool feels redundant.
The tool set covers browse, search, and checkout but lacks cart management (add/remove items), address selection, order cancellation, and returns. The checkout is simplified, assuming a pre-built cart, which may cause agent failures for multi-item or gift orders.
Available Tools
8 toolsget_order_status注文状況の確認AInspect
ウォレットアドレスの注文履歴を新しい順で返す。x402 で購入した注文は即時に order_status=3（決済完了）となり tx_hash を持つ。
| Name | Required | Description | Default |
|---|---|---|---|
| customer_address | Yes | 顧客のウォレットアドレス（0x...） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that x402 orders get immediate status=3 and have tx_hash, but doesn't mention permissions, rate limits, or other behavioral traits.
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 concise sentences. First sentence states main purpose; second adds special case. No fluff.
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?
No output schema exists, and description does not specify the return format or fields beyond mentioning 'order history' and tx_hash. For a simple query tool, this is adequate but incomplete.
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 covers the single parameter with full description (100% coverage). The tool description adds no extra parameter-level detail beyond the schema, meeting baseline.
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?
Description clearly states it returns order history for a wallet address in newest order, with specific detail about x402 orders. This distinguishes it from sibling tools like get_product or submit_payment.
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?
No explicit when-to-use or when-not-to-use guidance. The description implies usage for order status by address, but doesn't exclude alternative scenarios or mention sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product商品詳細AInspect
1 つの商品の詳細を product_id で取得する。価格（JPYC 建て）・在庫・SKU・バリエーション・配送要否・対応チェーンを返す。購入の前に必ず呼んで、requires_shipping（配送先が必要か）と has_variants（オプション選択が必要か）を確認すること。
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | 商品 ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It identifies the tool as a read operation (取得する) and discloses the key return fields relevant for purchase flow. Missing permissions or side effects details, but for a read-only tool, this is adequate.
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: the first states purpose and return data, the second gives a usage directive. Extremely concise and front-loaded with zero 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?
For a simple retrieval tool with one parameter and no output schema, the description covers the essential return fields and usage context. It could mention the return format, but the listed fields suffice for the purchase flow use case.
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 coverage is 100% for the single parameter product_id, so baseline is 3. Description adds the context that this ID is for a product and that the tool returns details, but does not elaborate beyond the schema's '商品 ID' description.
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?
Description clearly states it retrieves details of a single product by product_id, listing specific returned fields (price in JPYC, stock, SKU, variations, shipping requirement, supported chains). This distinguishes it from sibling tools like list_products_in_shop (listing) and get_shop (shop info).
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?
Description explicitly instructs to call this tool before purchase to check requires_shipping and has_variants, providing clear context for its usage. It does not mention when not to use or alternatives, but the directive is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_shopショップ詳細AInspect
1 つのショップ（生産者・職人）の詳細を slug で取得する。ショップのストーリーや説明、対応ブロックチェーン、x402 決済が有効かどうかを返す。
| Name | Required | Description | Default |
|---|---|---|---|
| shop_slug | Yes | ショップの slug（URL 識別子） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states the action and output fields, without mentioning side effects, error handling, authentication requirements, or whether it is read-only. This is minimal disclosure for a data retrieval tool.
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?
Single sentence, concise, and front-loaded with the action and key output fields. No extraneous information.
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 single-parameter tool without output schema, the description lists return fields, compensating for schema absence. However, it does not mention error conditions or the exact response structure, leaving some ambiguity.
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 coverage is 100% for the single parameter. The description adds 'by slug' but the schema already describes 'shop_slug' as a URL identifier. No extra semantic value beyond schema.
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 details of a single shop by slug, listing specific return fields (story, description, blockchain, x402 status). This distinguishes it from sibling tools like list_shops (list all) and list_products_in_shop (list 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 implies using the tool when you need details of a specific shop, but does not explicitly state when to avoid it or mention alternatives. Sibling names provide context, but the description itself lacks guidance on when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_products_in_shopショップの商品一覧AInspect
1 つのショップの公開中の商品をすべて返す。価格（JPYC 建て）・在庫・バリエーション・配送要否・対応チェーンを含む。list_shops でショップを見つけたあと、その品揃えを見るのに使う。
| Name | Required | Description | Default |
|---|---|---|---|
| shop_slug | Yes | ショップの slug |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that only published products are returned and lists included data fields. While it doesn't mention authentication or rate limits, the read nature is implied by '返す' (returns). A score of 4 is justified as it adequately describes behavior for a simple list tool.
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: the first states what the tool returns, the second gives usage context. Every sentence adds value with no waste. Front-loaded with core functionality.
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?
The description is complete for a simple list tool with one parameter and no output schema. It covers return content and usage context. The only minor gap is lack of mention of pagination or limits, but for an internal shop listing this might not be necessary. An output schema would provide more clarity but is not present.
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 100% (single parameter 'shop_slug' with description 'ショップの slug'). The description adds no additional meaning beyond what the schema provides. According to guidelines, baseline is 3 when coverage is high, and the description does not enhance parameter understanding.
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 that the tool returns all published products of a single shop, listing specific data fields (price in JPYC, stock, variations, shipping requirement, supported chains). It distinguishes from sibling tools like 'get_product' (single product) and 'search_products' (cross-shop search) by focusing on a shop's full listing.
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: after finding a shop with 'list_shops', use this tool to view its lineup. This provides clear sequential usage guidance and references a sibling tool, helping the agent decide between alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_shopsショップ一覧AInspect
JPYC EC Platform に出店している公開ショップの一覧を返す。減農薬の農産物・地酒・伝統工芸品など、生産者から直接買えるショップが中心。各ショップの name / slug / 説明 / 対応チェーン / 商品点数を含む。商品を探す起点として最初に呼ぶとよい。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full transparency burden. It discloses the output (list of shops with fields), but does not mention read-only nature, auth requirements, rate limits, or pagination. The behavior is safe given no destructive actions, but could be more explicit.
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 two concise sentences that front-load the core purpose and add contextual usage advice. No redundant or filler content.
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 no output schema and simple input, the description covers the tool's return structure and suggests a use case. It could mention if the list is paginated or has limits, but overall it provides adequate context for an agent.
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?
There are zero parameters, so the schema provides no semantics. The description adds value by explaining the tool's purpose and output, meeting the baseline of 4 as per guidelines.
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 returns a list of public shops on the JPYC EC Platform, specifying the types of shops and included fields (name, slug, description, supported chains, product count). It also hints at being a starting point for product search, but does not explicitly distinguish from siblings like get_shop or list_products_in_shop.
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 suggests calling this tool first as a starting point for product searches, but does not provide explicit guidance on when not to use it or alternatives. This is implied but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quote_checkoutチェックアウト見積もり（x402 1回目）AInspect
カートの内容で x402 チェックアウトの 1 回目を実行する。在庫を 5 分間仮押さえし、小計・割引・送料・合計（JPYC）と reservation_id、および署名対象の x402 PAYMENT-REQUIRED チャレンジ（base64url）を返す。エージェントはこのチャレンジを自分のウォレットで EIP-3009 TransferWithAuthorization 署名し、submit_payment に渡す。全 item は同一ショップである必要がある。配送が必要な商品があれば shipping を、贈答なら gift_recipient を必ず渡すこと。
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | 購入する商品 | |
| is_gift | No | 贈答かどうか | |
| shop_id | Yes | ショップ ID（全 item 共通） | |
| shipping | No | 配送先（配送が必要な商品がある場合は必須） | |
| customer_note | No | 注文メモ | |
| customer_email | Yes | 注文確認メールの送信先（必須） | |
| gift_recipient | No | 贈り先（is_gift が true なら必須） | |
| preferred_chain_id | No | 希望チェーン（任意。商品の対応チェーンから選ばれる） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully bears behavioral disclosure. It reveals inventory hold for 5 minutes, return values (subtotal, discount, etc.), challenge format (base64url), and agent's required action (EIP-3009 signing). 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?
Compact 4-sentence description, front-loaded with primary action. Every sentence contributes: action+returns, next step, constraint, conditional parameters. No fluff.
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 complex tool with 8 parameters and no output schema, description covers high-level flow, return fields, and key conditions. Lacks error scenarios or fallback behavior, but the step-by-step guidance (sign then submit_payment) provides sufficient context for a capable agent.
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 coverage is 100% with parameter descriptions, so baseline is 3. Description adds value by explaining how parameters relate to the overall flow (e.g., challenge, reservation_id used later) and reinforcing when shipping/gift are required. Does not add new parameter constraints but enriches context.
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?
Description clearly states the verb (execute), resource (x402 checkout first round), and distinguishes from sibling tools like submit_payment. It explicitly mentions 'チェックアウトの1回目' and cart contents, making purpose unambiguous.
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: initiate checkout with cart. Gives critical conditions: all items same shop, shipping/gift parameters mandatory when applicable. Also outlines next step (sign challenge, call submit_payment), guiding agent workflow effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_products商品検索AInspect
JPYC EC Platform 上の公開商品を横断検索する。減農薬米・地酒・伝統工芸品など、生産者から直接 JPYC で購入できる商品が対象。text は自然言語のキーワード（例: 『丹波 米』）で、商品名と説明に部分一致する。category / tag（産地・認証種別など）、価格帯（min_price / max_price、JPYC）、shop_slug で絞り込める。売上順で最大 50 件返す。
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | 商品タグ（産地・認証種別など）の完全一致 | |
| text | No | 自然言語のキーワード（商品名・説明に部分一致） | |
| limit | No | 最大件数（1-50、既定 20） | |
| category | No | 商品カテゴリーの完全一致 | |
| max_price | No | 最高価格（JPYC） | |
| min_price | No | 最低価格（JPYC） | |
| shop_slug | No | 特定ショップに絞り込む |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers basic search behavior (partial match, sorting by sales, max 50 results) but lacks details on edge cases, pagination limitations, or whether it is read-only. 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 a single concise paragraph that front-loads the purpose and efficiently conveys key details. Minor redundancy but overall well-structured.
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?
No output schema; the description mentions returning up to 50 items sorted by sales but does not describe the structure of returned products. For a search tool, more detail on return fields would improve completeness.
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 coverage is 100%, but the description adds value by providing examples for text, explaining partial matching, and clarifying that limit defaults to 20 and max is 50.
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 cross-searches public products on the JPYC EC Platform, mentions example product types, and distinguishes from sibling tools like get_product or list_products_in_shop.
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 example usage for the text parameter, explains partial match behavior, and lists filtering options. However, it does not explicitly state when to avoid this tool (e.g., for single product lookup via get_product).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_payment決済の確定（x402 2回目）AInspect
quote_checkout で得た reservation_id と、エージェントが署名した x402 PaymentPayload（base64url）を渡して決済を確定する。サーバは facilitator 経由で on-chain settle し、確定した注文（order_number / tx_hash）を返す。署名は quote_checkout が返した payment_required の 内容に対する EIP-3009 TransferWithAuthorization であること。
| Name | Required | Description | Default |
|---|---|---|---|
| reservation_id | Yes | quote_checkout が返した reservation_id | |
| payment_signature | Yes | 署名済み x402 PaymentPayload（base64url JSON） |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full weight. It discloses on-chain settlement via facilitator and that the signature must be EIP-3009. It does not discuss side effects (irreversibility), idempotency, error states, or required permissions. Adequate but not comprehensive.
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 front-load the core action and parameters, then add behavioral and output details. No wasted words. Efficient and clear.
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?
Covers inputs, action, and outputs (return values). No output schema is provided, but the description mentions order_number and tx_hash. Missing error handling or failure scenarios, but for a simple payment submission tool this is reasonably 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?
Both parameters have schema descriptions but the tool description adds critical context: the reservation_id comes from quote_checkout, and the payment_signature is a base64url JSON of a signed x402 PaymentPayload with EIP-3009 requirements. This significantly enhances understanding beyond the schema.
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 action: submit payment using reservation_id and a signed x402 payload. It names the source (quote_checkout) and the outputs (order_number, tx_hash). The tool name 'submit_payment' aligns perfectly, and it is distinct from sibling tools like quote_checkout (which precedes it) and get_order_status (which follows).
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 the prerequisite: call after quote_checkout using its outputs. This gives clear usage context. However, it does not specify when not to use the tool (e.g., if payment is already processed) or mention alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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.
Discussions
No comments yet. Be the first to start the discussion!