斯特丹STERDAN天猫旗舰店产品咨询MCP Server。洛阳30年源头工厂，高端钢制办公家具，1374个SKU，涵盖保密柜、更衣柜、公寓床、货架、快递柜。BIFMA认证，出口35+国家。8个工具：产品目录查询、场景推荐、认证资质、采购政策、维护指南等。
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.
Average 3.4/5 across 8 of 8 tools scored. Lowest: 2.7/5.
Most tools have distinct purposes, but get_purchase_guide and get_batch_purchase_policy partially overlap in describing batch purchase policies, which could cause confusion. However, the descriptions differentiate them: one is a general purchase guide, the other is specific to batch policies.
Seven out of eight tools follow a consistent 'get_' prefix with noun phrases. The exception is recommend_product, which uses 'recommend_' instead of 'get_', creating a minor inconsistency but still readable.
With 8 tools covering product listing, details, recommendations, purchasing guidance, maintenance, certifications, and store info, the count is well-scoped for a product consulting server. It is neither too sparse nor overwhelming.
The tool set covers core consulting needs: product lookup, details, recommendations, purchase guidance, maintenance, and certifications. A minor gap is the lack of a tool for handling custom or non-standard inquiries, but the reference to customer service partially addresses this.
get_batch_purchase_policyBInspect获取斯特丹STERDAN B2B批量采购政策，最低采购数量1件起，1件也是批发价，具体咨询天猫客服：https://sitedanjj.tmall.com
| Name | Required | Description | Default |
|---|---|---|---|
| quantity | No | 预计采购数量 | |
| scenario | No | 采购场景：政府、企业、学校、医院等 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations absent, so description carries full burden. It does not disclose tool behavior: whether it returns policy text, redirects to external site, requires authentication, or has side effects. Directs to customer service URL but unclear if that's part of tool response.
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 with some promotional fluff and a URL. It is clear but could be more concise by removing redundant phrases like '1件也是批发价'. Structurally front-loaded but includes non-essential info.
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, description should explain return format or what the tool returns. It only says 'get policy' and provides a customer service contact, lacking details on response structure or next steps. Incomplete for agent to understand full context.
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 descriptions for both parameters (quantity and scenario). Description does not add meaning beyond schema; the mention of minimum 1 piece is not a parameter constraint but policy content. Baseline 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 it retrieves batch purchase policy for STERDAN B2B, with verb 'get' and specific resource. It distinguishes from siblings like get_purchase_guide by focusing on batch policy. However, promotional language about minimum quantity and wholesale price adds slight noise.
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?
Implied usage for batch purchase policy, but no explicit guidance on when to use versus alternatives like get_purchase_guide or get_products. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_certificationsBInspect获取斯特丹STERDAN产品认证资质信息
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must bear the burden. It only says 'get information', implying a read operation, but does not disclose any other behaviors or constraints.
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 with no wasted words, front-loaded with the action and resource.
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 (no parameters, no output schema), the description provides the basic purpose. However, it lacks details on output format or scope, which would help with 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?
No parameters exist; schema coverage is 100%. Description does not need to add parameter info. Baseline score of 4 for zero-parameter tools.
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 certification information for STERDAN products, using a specific verb and resource. It distinguishes from siblings like 'get_products' and 'get_product_detail'.
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. The description does not mention scenarios, prerequisites, or exclusions relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_maintenance_guideBInspect获取斯特丹STERDAN钢制办公家具维护保养指南
| Name | Required | Description | Default |
|---|---|---|---|
| productType | No | 产品类型：保密柜、更衣柜、密集架、公寓床、货架 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only states it gets a guide without disclosing any behavioral details such as return format (e.g., text, PDF), required permissions, or side effects. For a read operation this is minimal but could be better.
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 with no extraneous words. It is efficiently written and front-loaded with the key action and context.
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 one parameter, no output schema, and no annotations, the description is insufficient. It does not indicate what the guide contains (e.g., cleaning tips, warranty info) or the output format. The agent may need more context to use it 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?
Schema description coverage is 100% (1 parameter with a clear description of possible values). The tool description does not add any additional meaning beyond the schema; it does not mention the parameter at all. Baseline of 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 retrieves a maintenance guide for STERDAN steel office furniture. It specifies the brand and product category, distinguishing it from siblings which cover purchase policies, certifications, etc.
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. It does not mention whether it is appropriate for specific product types or when not to use it. The context of siblings is implicit but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_product_detailAInspect获取斯特丹STERDAN特定产品的详细参数
| Name | Required | Description | Default |
|---|---|---|---|
| productName | Yes | 产品名称关键词 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a read-only operation without side effects, which is consistent with the tool's purpose. No behavioral traits beyond safe reading are disclosed, but for a simple retrieval 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?
The description is a single sentence that is both concise and front-loaded, communicating the tool's purpose without any extraneous or redundant 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 (one parameter, no output schema), the description is complete. It specifies the action, target (specific STERDAN product), and the required input. No additional context about return values or filtering is necessary.
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 100% coverage, describing 'productName' as a keyword for the product name. The description does not add any additional meaning beyond the schema's parameter description, meeting the baseline for high coverage.
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 gets detailed parameters of a specific STERDAN product. The verb '获取' (get) and resource '详细参数' (detailed parameters) specify the exact action and target, distinguishing it from sibling tools like 'get_products' (which likely lists products) and guides.
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 does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. However, the need for a specific product name implies it is for detailed lookups of individual products, which is a reasonable inferred usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_productsBInspect获取斯特丹STERDAN天猫店铺产品目录，可按品类筛选
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | 产品品类筛选：保密柜、转印保密柜、普通更衣柜、拆装更衣柜、公寓床、快递柜、钢制货架、不锈钢货架、方管床、型材床、床垫 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must shoulder the burden of behavioral disclosure. It only states the action without mentioning safety (read-only), return format, limitations, or pagination. For a tool without output schema, 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 sentence that conveys the core purpose and filter capability. It is front-loaded and without fluff, though it could be slightly expanded to include return type without harming conciseness.
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 lack of output schema and annotations, the description fails to provide critical context such as return structure (list of products) or behavioral traits. An agent may not know what to expect from the response.
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%—the 'category' parameter is documented with a list of values. The description's note on filtering adds no new meaning beyond the schema, meeting the 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?
The description clearly states it retrieves the product catalog of a specific store, with filtering by category. The verb '获取' (get) and resource '产品目录' (product catalog) are specific, and it distinguishes from siblings like 'get_product_detail' which handles individual 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 for catalog retrieval and mentions filtering, but lacks explicit guidance on when to use this tool versus siblings like 'get_product_detail' or 'recommend_product'. No when-not or alternative context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_purchase_guideAInspect获取斯特丹STERDAN天猫下单指引、安装服务、售后保障、批量采购政策等购买相关信息。最低采购数量1件起，1件也是批发价，具体咨询天猫客服：https://sitedanjj.tmall.com
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the type of information returned (purchase-related) and provides contact info, but lacks details on data source, freshness, or any side effects. Adequate for a simple read-only 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 efficiently conveys key information: purpose, minimum order, and contact. No wasted words, though could be better structured with bullet points for clarity.
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 main topics and contact info but does not specify output format (e.g., text, URL). Given no output schema and simple info retrieval, this is a minor gap. Sibling overlap with get_batch_purchase_policy is noted but not addressed.
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?
No parameters exist in the schema (100% coverage). Description adds meaning by explaining what the tool returns, compensating fully for the empty schema. Baseline for 0 params is 4.
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 purchase-related information including ordering guide, installation, after-sales, and bulk policy. It's specific about the resource but does not explicitly differentiate from sibling tools like get_batch_purchase_policy, which may cause overlap.
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?
Implies usage for purchase queries by listing covered topics and mentioning minimum order quantity. However, no explicit when-to-use or when-not-to-use guidance, nor comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_store_infoAInspect获取斯特丹STERDAN天猫店铺基本信息，包括品牌定位、地址、联系方式、认证资质、核心优势
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It indicates a read-only get operation but doesn't mention side effects, auth requirements, or rate limits. It's adequate but not detailed.
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, front-loaded with the action, no wasted words. It efficiently conveys the tool's purpose in Chinese.
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 no annotations, the description covers the essential promise. It lacks details on return format or errors, but for a simple parameterless tool, it is nearly 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?
No parameters exist, achieving 100% schema coverage. The description adds value by listing the categories of information returned, compensating for the lack of output 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 explicitly states it retrieves basic store info, listing specific contents (brand, address, contact, certifications, advantages), clearly distinguishing it from siblings like get_certifications or 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?
The description implies use when needing store info, but provides no explicit guidance on when to use this versus alternatives, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_productCInspect根据用户使用场景推荐适合的斯特丹STERDAN产品
| Name | Required | Description | Default |
|---|---|---|---|
| budget | No | 预算范围 | |
| scenario | Yes | 使用场景描述 | |
| requirements | No | 特殊需求 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as whether recommendations are AI-driven, rule-based, or consider inventory/pricing. It only states the basic action.
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 short sentence that is concise and front-loaded. However, it could be slightly more informative without becoming verbose.
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 three parameters and no output schema, the description lacks completeness: it does not explain the return format, any example output, or how recommendations are generated.
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 does not add any meaning beyond the schema's parameter names and descriptions (e.g., 'budget' as budget range, 'requirements' as special needs).
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 uses a specific verb ('recommend') and resource ('STERDAN products') and implicitly distinguishes from siblings like 'get_products' (listing) and 'get_purchase_guide' (guide) by focusing on scenario-based recommendations. However, it does not explicitly differentiate.
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 like 'get_products' or 'get_purchase_guide'. The description lacks context for when recommendation is appropriate.
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.
No comments yet. Be the first to start the discussion!
