agentmart
Server Details
First AI Agent e-commerce marketplace with 74+ AI products, MCP protocol, and Alipay payments
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ai-gaoqian/agentmart-mcp-server
- GitHub Stars
- 0
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 3.3/5 across 6 of 6 tools scored.
Each tool has a distinct purpose: creating orders, viewing hot products, getting details, listing categories, searching, and trying a free demo. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern (e.g., create_order, get_hot_products, search_products), making the intent clear and predictable.
Six tools cover the core functionality of an AI marketplace without being excessive or insufficient. The count is well-scoped for its purpose.
The set covers the main user journey: discovery (search, categories, hot products), details, trial, and ordering. Missing account management or order history are minor gaps.
Available Tools
6 toolscreate_orderAInspect
在AgentMart创建购买订单。返回支付链接，用户完成支付后即可使用服务。
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | Yes | 买家用户ID | |
| quantity | No | 购买数量，默认1 | |
| product_id | Yes | 要购买的商品ID |
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 reveals the return of a payment link and a two-step process (payment before service), but lacks details on idempotency, error states, or side effects beyond order creation.
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, front-loaded sentence with no redundancy, but could be slightly more structured (e.g., breaking steps).
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 absence of an output schema, the description mentions the payment link, but omits response format, error conditions, and behavior for invalid inputs. Adequate for a straightforward order creation.
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 parameters are well-documented. The description adds no additional parameter meaning beyond the schema; it only explains the overall result.
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 ('create a purchase order') and the returned resource ('payment link'), distinguishing it from sibling tools that are read-only or exploratory (e.g., get_hot_products, 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 implies usage context (creating an order after selecting a product) but does not explicitly state when to use this tool over alternatives or mention any prerequisites or restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hot_productsAInspect
获取AgentMart平台当前最热门的AI商品和服务推荐。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 返回数量，默认10 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so description carries full burden. It only states 'get hottest recommendations' without disclosing how 'hot' is determined, whether results are cached, or if any authentication is needed. Minimal behavioral insight beyond the tool name.
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, perfectly front-loaded with the verb and resource. No wasted words or extraneous 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?
For a simple list tool with one optional parameter and no output schema, the description is adequate. It specifies what is returned (hot products) but lacks details on the format or whether it returns full product info. Given low complexity, this is minimally 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 description coverage is 100% for the single parameter 'limit' with a clear description (return quantity, default 10). The tool description adds no additional meaning beyond what the schema provides, so baseline of 3 applies.
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 retrieves the hottest AI products and services on AgentMart, using a specific verb and resource. It distinguishes from siblings like get_product_detail (specific product) and search_products (search-based).
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 implies usage for trending recommendations but does not explicitly state when to use this tool versus alternatives like search_products or list_categories. No exclusions or contextual guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_detailCInspect
获取AgentMart商品的详细信息，包括价格、功能描述、使用方式。
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | 商品ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It states it returns price, function, and usage, but does not mention whether the operation is read-only, what permissions are needed, or any side effects. Given the lack of annotations, this is insufficient.
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, clear sentence in Chinese. It is front-loaded with the main purpose. However, it is only in Chinese, which may hinder non-Chinese agents, but conciseness is good.
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 tool with one parameter and no output schema, the description adequately covers the basic information returned. However, it omits potential additional fields or response format details, leaving some ambiguity for the 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?
The input schema covers 100% of parameters with description '商品ID' (product ID). The description does not add extra meaning beyond this. Baseline is 3 since schema coverage is high, but the description fails to provide additional context like format or constraints.
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 retrieves detailed product information including price, function description, and usage method. It distinguishes from sibling tools like search_products (which likely returns summary) and get_hot_products (which returns popular items). However, it lacks specificity about the verb 'get' and the resource 'product detail' is clear but not overly precise.
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 guidance on when to use this tool versus alternatives such as search_products or list_categories. The description does not indicate contexts where this tool is appropriate or not, leaving the agent to infer its purpose solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesAInspect
列出AgentMart平台所有商品分类及其商品数量。
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 describes a read-only list operation but does not explicitly state behavioral traits like idempotency, authentication needs, or side effects. The action 'list' implies safety, but explicit disclosure is lacking.
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, front-loaded sentence with no wasted words. It is appropriately concise for the tool's simplicity.
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 no parameters and no output schema, the description fully covers the needed context. It states what is listed (categories and counts) and implies no return values or constraints missing.
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 zero parameters, so schema coverage is 100%. The description adds no parameter meaning because none exist. This aligns with the baseline score of 4 for zero 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?
The description clearly states the tool's purpose: listing all product categories and their counts on the AgentMart platform. It uses a specific verb ('list') and resource ('categories'), and it distinguishes itself from siblings that focus on orders, product details, search, or trials.
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 usage for obtaining a category list, but it does not provide explicit guidance on when to use it versus alternatives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_productsCInspect
搜索AgentMart平台的AI商品和服务。支持按关键词、分类搜索，找到适合的AI工具、技能、API服务、内容创作和数据分析服务。
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | No | 搜索关键词，如"副业"、"PPT"、"数据分析"、"API"等 | |
| category | No | 商品分类 | |
| max_price | 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 full burden. It adds minimal behavioral information beyond the schema, such as the scope (AgentMart platform) and types of services, but does not disclose important traits like return format, pagination, or whether it is a read-only operation.
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 sentence that efficiently conveys the tool's purpose and supported search methods. No redundant or verbose language is present.
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 three optional input parameters, the description lacks information about the return format (e.g., list of items, metadata). It mentions finding suitable tools, but does not specify what the response contains or how results are structured.
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 reiterates that keyword and category are supported (matching schema) but does not add new semantic details or examples beyond what the schema already provides.
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 searches for AI products and services on the AgentMart platform, mentioning supported criteria like keyword and category. It distinguishes from sibling tools like get_product_detail (single product) and get_hot_products (hot items), though it does not explicitly contrast them.
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 no explicit guidance on when to use this tool versus alternatives (e.g., get_hot_products, get_product_detail). Usage context is implied but not stated, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
try_free_demoCInspect
免费体验AI副业赚钱助手。首次使用免费，AI会根据你的情况推荐最适合的副业方向和实操步骤。
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | 你想了解的副业问题，如"我没技术能做什么副业"、"怎么用AI赚钱" | |
| user_id | Yes | 用户唯一标识 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It only states it's free and what it does, but omits whether it modifies state, requires authentication, has rate limits, or what side effects occur.
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, no redundancy, directly conveys the main purpose. Could be slightly more structured but not wasteful.
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, yet the description does not explain what the tool returns (e.g., text, list, steps). This is a significant gap for an agent to understand the response format.
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 the schema already documents both parameters. The description adds no extra semantic context about the parameters, 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 the tool is for a free trial of an AI side business assistant that recommends directions based on user input. It is distinct from sibling tools which focus on products and orders.
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 first-time use but provides no explicit guidance on when to use this tool vs alternatives, no when-not-to-use context, and no mention of prerequisites or conditions.
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!