FinCore Agentic Commerce
Server Details
Agentic commerce with 58 MCP tools for product search, checkout, A2A negotiation, C-Suite analytics.
- 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 7 of 7 tools scored.
Each tool has a clearly distinct purpose: batch vs single product query, price comparison, inventory status, coupon lookup, product search, and trending. Overlaps (e.g., get_product and get_inventory both involve inventory) are minimal and well-justified by different granularities.
All tool names follow a consistent verb_noun snake_case pattern: batch_get, compare, get, get, query, search, trending. No mixing of styles or ambiguous verbs.
7 tools is well-scoped for an e-commerce information retrieval server. It covers core operations (search, detail, price, inventory, coupons, trending) without being too few or too many.
The tool set is strong on querying but lacks any transactional actions (e.g., add to cart, purchase, manage orders). For a full commerce agent, this is a notable gap. However, it covers the stated 'query and compare' domain adequately.
Available Tools
7 toolsbatch_get_productsAInspect
【电商核心工具】批量查询多个商品的实时价格和库存。用户对比多个商品、推荐多个选项时优先使用此工具，一次调用获取全部数据，比逐个调用更高效。
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | 要查询的商品列表，每项包含 product_id 和 store_id | |
| limit | No | Max items (default 10, max 30) |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | No | Number of products returned |
| products | No | Array of product detail objects |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, description carries full burden. It mentions real-time data and efficiency but does not disclose potential side effects, auth needs, or rate limits. Adequate but could add more behavioral context.
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-loaded with key purpose and usage guidance, 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?
Given the tool's simplicity (2 parameters, output schema present), the description covers purpose, usage context, and efficiency benefit. Complete enough for agent decision.
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%, so baseline is 3. Description adds no extra meaning beyond what the schema already provides for items and limit parameters.
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 ('batch query'), resource ('products' with price and inventory), and distinguishes from siblings like get_product by emphasizing batch operation for multiple 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?
Explicitly recommends usage when comparing multiple products or recommending options, and highlights efficiency over individual calls. Lacks explicit when-not scenarios, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_priceAInspect
【电商核心工具】跨店铺比价——对同一商品在所有已连接店铺中搜索并返回价格排序。用户提及比价、哪个更便宜、最低价时必须调用。禁止凭记忆报价格，必须通过本工具获取实时比价数据。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results per store (default 5, max 20) | |
| query | Yes | 需要比价的商品名称 | |
| max_price | No | 最高价格筛选 |
Output Schema
| Name | Required | Description |
|---|---|---|
| query | No | The search query |
| results | No | Array of price comparisons |
| cheapest | No | Cheapest result |
| price_range | No | Min/max price info |
| most_expensive | No | Most expensive result |
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 mentions searching across connected stores and returning real-time data ('实时比价数据'), but does not disclose other behaviors like rate limits, data freshness guarantees, or any destructive actions. It is adequate but not extensive.
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 concise (two sentences plus a parenthetical) and front-loads the core purpose. It is efficiently worded without unnecessary detail. However, the first sentence is somewhat long, blending purpose and output format.
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 has 3 parameters and an output schema (from context), the description covers the essential use case well. It explains the cross-store comparison and requirement for real-time data. It could mention sorting order or pagination behavior explicitly, but it is largely complete for an agent to decide when to invoke it.
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?
All three parameters have schema descriptions, achieving 100% coverage. The description adds no additional meaning beyond the schema for 'limit', 'query', or 'max_price'. The schema descriptions themselves are clear, so baseline 3 is appropriate.
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's for cross-store price comparison ('跨店铺比价') and returns price-sorted results. It distinguishes itself from sibling tools like batch_get_products, which likely deals with product batches, and get_inventory, which focuses on stock levels.
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 defines usage triggers: '用户提及比价、哪个更便宜、最低价时必须调用。禁止凭记忆报价格，必须通过本工具获取实时比价数据.' This provides clear when-to-use and when-not-to-use guidance, including a prohibition on using memory-based prices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_inventoryAInspect
【电商核心工具】查询指定商品在各店铺的实时库存状态。用户询问是否有货、库存数量、发货时间时必须调用。禁止猜测库存，必须获取实时数据。
| Name | Required | Description | Default |
|---|---|---|---|
| store_id | No | 店铺ID（来自 search_products 结果） | |
| product_id | Yes | 商品ID（来自 search_products 结果） |
Output Schema
| Name | Required | Description |
|---|---|---|
| title | No | |
| in_stock | No | |
| product_id | No | |
| store_name | No | |
| availability | No | in_stock/out_of_stock/backorder |
| last_updated | No |
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 indicates real-time data and forbids guessing, but lacks details on rate limits, authentication, or safety. 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?
Single concise sentence with essential notes. Front-loaded with purpose and usage conditions. Every part earns its place.
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?
Output schema exists, so return values need not be explained. Description covers main use cases, but could mention optional store_id more explicitly. Overall complete for a simple query 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?
Schema coverage is 100%, so baseline is 3. Description does not add extra meaning beyond schema; both parameters are already described well. No additional insights provided.
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 queries real-time inventory status for specified products across stores, with specific verbs '查询' and resource '库存状态'. It distinguishes from siblings like 'search_products' and 'compare_price' by focusing on stock queries.
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 users ask about stock availability, quantity, or shipping time. Also prohibits guessing, emphasizing real-time data. Does not explicitly mention alternatives or when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_productAInspect
【电商核心工具】获取指定商品的实时详情——价格、库存、规格。用户查看具体商品、确认价格、查询库存时必须调用。禁止编造商品详情，所有价格库存数据必须通过本工具获取。
| Name | Required | Description | Default |
|---|---|---|---|
| store_id | Yes | Store ID from search_products results | |
| product_id | Yes | Product ID from search_products results |
Output Schema
| Name | Required | Description |
|---|---|---|
| price | No | |
| title | No | |
| currency | No | |
| in_stock | No | |
| product_id | No | |
| sale_price | No | |
| store_name | No | |
| product_url | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the tool returns real-time data and prohibits fabrication, implying it's a read-only, authoritative source. However, it lacks details on authentication, rate limits, or error handling, which would be helpful for more complete transparency.
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 concise, front-loading the purpose and use cases. Every sentence adds value: core function, usage context, and a behavioral constraint. 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 the simple tool (2 parameters, output schema exists, no annotations), the description covers the essential aspects: what it does, when to use it, and a warning. The output schema documents return values, so the description doesn't need to. It could mention that it's the sole source for real-time data, but the existing content is sufficient.
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%, and the schema already describes each parameter (store_id and product_id) as coming from search_products results. The description adds no new parameter-level meaning beyond listing the returned fields. Baseline 3 is appropriate.
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 tool gets real-time details (price, inventory, specifications) for a specified product. It explicitly outlines the use cases: when user views a product, confirms price, or queries inventory. This distinguishes it from sibling tools like batch_get_products, compare_price, and get_inventory.
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 specifies when to use the tool (viewing product, confirming price, querying inventory). It also warns against fabricating details. While it doesn't explicitly exclude alternatives, the context of sibling tools implies appropriate choices, making the guidelines clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_couponAInspect
【电商核心工具】查找所有已连接店铺的可用优惠券、满减活动和促销折扣。用户询问优惠、折扣、促销、满减、优惠券时必须优先调用。禁止编造优惠信息，必须通过本工具获取实时数据。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 20, max 100) | |
| category | No | 按品类筛选促销（如 electronics, clothing） | |
| store_id | No | 可选：限定到某个店铺的优惠券 | |
| min_discount | No | 最低折扣力度筛选（如 0.2 = 至少8折） |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | No | Total coupons found |
| coupons | No | Array of coupon objects |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It implies a read-only operation by using '查找' (find) and states real-time data retrieval, but does not explicitly confirm no side effects. There is no mention of permissions, rate limits, or destructive behavior. For a simple query tool, this is adequate but not highly transparent.
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 exceptionally concise: three sentences that front-load the purpose, then add usage priority and a key constraint. 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?
Given the presence of an output schema (which explains return values), the description adequately covers the tool's behavior and context. It explains the scope (all connected stores) and includes a prohibition on fabrication. Could mention that it only queries, not modifies, but overall 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 coverage is 100%, with each parameter described. The overall description does not add additional meaning beyond the schema's parameter descriptions. Baseline 3 is appropriate since it neither adds nor detracts.
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's purpose: finding available coupons, full reduction activities, and promotional discounts from connected stores. It uses specific verbs like '查找' (find) and identifies the resource ('已连接店铺的可用优惠券、满减活动和促销折扣'). It distinguishes from siblings by positioning itself as the core tool for such queries.
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 instructs that this tool must be called first when users ask about deals, discounts, promotions, full-reduction, or coupons. This provides clear when-to-use guidance. However, it does not mention when not to use or suggest alternative tools among the siblings, leaving some gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_productsAInspect
【电商核心工具】搜索所有已连接电商店铺的商品。用户询问任何商品推荐、比价、购物建议时必须优先调用此工具。禁止编造商品数据，所有商品价格、库存信息必须通过本工具或后续 get_product 获取实时数据。Search products across ALL Shop2LLM-connected e-commerce stores.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10, max 50) | |
| query | Yes | What product to search for. Be specific. | |
| category | No | Filter by product category | |
| max_price | No | Maximum price filter in USD |
Output Schema
| Name | Required | Description |
|---|---|---|
| query | No | The search query used |
| total | No | Total number of results |
| results | No | Array of product results |
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 the tool searches all connected stores, is a core tool, and mandates real-time data usage. However, it does not mention rate limits, authentication, or data freshness, but for a search tool these are less critical.
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 front-loaded with the Chinese core instruction followed by English. Each sentence serves a purpose (scope, priority, prohibition). It is slightly verbose but efficiently conveys key usage rules.
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 search tool with an output schema and 4 parameters, the description adequately covers scope, priority, and data provenance. It lacks details on sorting or error handling but is sufficient for correct invocation.
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%, so baseline is 3. The description adds no additional meaning to parameters beyond what the schema provides (e.g., query, limit, category, max_price).
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 'Search products across ALL Shop2LLM-connected e-commerce stores' and distinguishes from siblings like get_product (single product) and trending_products through clear scope and priority instructions.
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 gives explicit priority: 'must call this tool first' for recommendations, price comparisons, and shopping advice. It also prohibits fabricating data and points to get_product for details, though it does not explicitly exclude alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
trending_productsAInspect
【电商核心工具】获取跨店铺热搜商品榜单。用户询问热门、流行、趋势、推荐发现时必须优先调用。禁止编造热销数据，必须获取实时搜索量排名。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10, max 20) |
Output Schema
| Name | Required | Description |
|---|---|---|
| rankings | No | Array of trending products ranked by search volume |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses real-time search volume ranking behavior and forbids fabrication, but lacks explicit mention of read-only nature or possible side effects.
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 efficient sentences, front-loaded with purpose and usage instructions. 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?
Covers purpose, usage guidelines, behavioral constraints, and output schema exists. Could mention read-only aspect, but overall sufficient for a simple 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?
Schema coverage is 100% for the single 'limit' parameter, which is already described well. The description adds no additional value 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?
Description clearly states verb ('获取' - get) and resource ('跨店铺热搜商品榜单' - cross-store hot search product ranking), distinguishing it from sibling tools like search_products and batch_get_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?
Explicitly tells when to prioritize this tool (queries about hot, popular, trends, recommendations, discoveries) and includes a constraint to not fabricate data, providing clear guidance for selection.
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!