Coffee Company MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources like assets, payments, coupons, equity, and member data. However, 'assets_list' and 'member_benefit_list' both query member assets/coupons with similar descriptions, creating some ambiguity. The other tools are clearly differentiated by their specific functions.
Naming Consistency3/5
The naming follows a mostly consistent pattern of 'resource_action' (e.g., coupon_detail, equity_query), but there are notable deviations: 'assets_list' uses plural while others use singular (e.g., 'coupon_query'), and 'member_benefit_list' and 'member_benefits' have inconsistent naming despite similar domains. The pattern is readable but mixed.
Tool Count5/5
With 10 tools, the count is well-scoped for a coffee company server covering assets, payments, coupons, equity, and member management. Each tool serves a specific purpose in this domain, and the number is typical for such a scope, avoiding bloat or thin coverage.
Completeness4/5
The tool set provides good coverage for querying and managing member data, assets, coupons, equity, and payments, with clear CRUD-like operations for details and lists. Minor gaps exist, such as no explicit tools for creating or updating assets/coupons, but agents can likely work around this with the provided query tools for core workflows.
Average 3.2/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool queries and displays assets in a list view, implying a read-only operation, but doesn't specify whether it requires authentication, has rate limits, returns paginated results, or handles errors. For a tool with no annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the core purpose stated first in Chinese, followed by the HTTP API and a brief parameter note. There's no wasted text, and the structure is logical, though the inclusion of the HTTP API might be extraneous if not needed by the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no nested objects) and the presence of an output schema (which handles return values), the description is somewhat complete. However, with no annotations and minimal behavioral context, it lacks details on authentication, error handling, or performance traits that could be important for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal semantics beyond the input schema. It explains that 'member_id' is a 'Coffee Company会员ID' (Coffee Company member ID), which provides context not in the schema (which only has 'Member Id' as a title). However, with 0% schema description coverage and only 1 parameter, this is a baseline case; the description compensates slightly but doesn't fully detail format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '查询客户全部资产（优惠券 + 权益券），一览式展示' (Query all customer assets [coupons + equity coupons], displayed in a list view). It specifies the verb (query), resource (customer assets), and scope (all, including both coupon and equity coupon types). However, it doesn't explicitly differentiate from sibling tools like 'coupon_query' or 'equity_query', which might query subsets rather than all assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'coupon_query' or 'equity_query' that might be more appropriate for specific asset types, nor does it indicate prerequisites or contexts for usage. The only implicit clue is the mention of 'member_id', but this doesn't constitute usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool queries status, implying a read-only operation, but doesn't mention authentication needs, rate limits, error handling, or what the query returns (e.g., status codes, data format). The mention of the HTTP API adds minimal context but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. The inclusion of the HTTP API and parameter explanation is relevant but could be more streamlined. It avoids unnecessary fluff, but the structure could be improved by integrating the parameter info more seamlessly rather than as a separate 'Args' section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), the description doesn't need to explain outputs. However, with no annotations and a simple input schema, the description is minimally complete for a query tool but lacks depth on usage context and behavioral traits. It covers the basic purpose and parameter but misses operational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning for the single parameter 'order_id' by explaining it as '订单号' (order number), which clarifies its purpose beyond the schema's title 'Order Id'. However, with 0% schema description coverage and only one parameter, the description compensates adequately but doesn't provide additional details like format examples or constraints. The baseline is 3 due to low parameter count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '查询订单关联的券码生成状态' (query the coupon generation status associated with an order). It specifies the verb (query) and resource (coupon generation status for an order), making the intent understandable. However, it doesn't explicitly differentiate from sibling tools like 'coupon_detail' or 'equity_query', which might also relate to coupons or queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the corresponding HTTP API but doesn't specify use cases, prerequisites, or exclusions. For example, it doesn't clarify if this is for checking pending coupons, completed ones, or how it differs from 'coupon_detail' or other query tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a query operation ('查询'), implying it's read-only, but doesn't confirm if it's safe or has side effects. It mentions an HTTP API endpoint (POST /equity/detail) but doesn't explain authentication needs, rate limits, error conditions, or what the output contains. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: the first sentence states the purpose and details retrieved, the second gives the HTTP API, and the third lists the parameter with a brief explanation. There's no wasted text, and information is front-loaded. The minor deduction is for the slightly redundant listing of the parameter in the description when it's already in the schema, though this adds semantic value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to explain return values. However, with no annotations and a simple input schema (one parameter), the description adequately covers the basic purpose and parameter semantics but lacks usage guidelines and behavioral details like error handling or dependencies. It's minimally viable but leaves room for improvement in guiding the agent effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'order_id' by specifying it as '权益订单号' (equity order number), which clarifies its purpose beyond the schema's generic 'Order Id' title. With 0% schema description coverage and only one parameter, this compensation is effective. However, it doesn't provide format examples or validation rules, keeping it from a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '查询权益详情' (query equity details) and lists specific information it retrieves: '券码、状态、金额、核销次数等完整信息' (coupon codes, status, amount, redemption count, and other complete information). It distinguishes itself from siblings like 'equity_query' by focusing on detailed information for a specific order rather than general querying. However, it doesn't explicitly contrast with 'coupon_detail' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'equity_query' or 'coupon_detail'. It mentions the required parameter 'order_id' but doesn't explain prerequisites, such as needing an existing equity order. There's no explicit when-to-use or when-not-to-use context, leaving the agent to infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool queries status, implying a read-only operation, but doesn't specify authentication needs, rate limits, error conditions, or what the query returns beyond the high-level purpose. For a tool with zero annotation coverage, this is insufficient to inform the agent about operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the core purpose stated first. The additional lines for the HTTP API and parameter are brief and relevant. However, the inclusion of the HTTP API endpoint might be extraneous for an AI agent focused on tool invocation rather than implementation details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple query with 1 parameter), the presence of an output schema reduces the need to describe return values in the description. However, with no annotations and minimal behavioral context, the description is adequate but lacks depth. It covers the basic purpose and parameter semantics but misses usage guidelines and detailed behavioral traits, making it minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema. The schema only defines 'order_id' as a required string with no description. The description explains that 'order_id' is the '权益订单号' (equity order number), clarifying its purpose in the context of equity issuance. With 0% schema description coverage and 1 parameter, this compensates well, though it could provide more detail on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '查询权益发放状态（电子券是否发放成功）' translates to 'Query equity issuance status (whether electronic coupons have been successfully issued).' This specifies the verb (query) and resource (equity issuance status/electronic coupons). However, it doesn't explicitly differentiate from sibling tools like 'equity_detail' or 'coupon_query,' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the corresponding HTTP API endpoint but doesn't indicate prerequisites, scenarios for use, or comparisons to sibling tools like 'equity_detail' or 'coupon_query.' This leaves the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states this is a query/list operation, implying it's likely read-only, but doesn't confirm this or disclose other behavioral traits like authentication needs, rate limits, error handling, or response format. The mention of an HTTP API endpoint adds minimal context without specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first. The additional lines for the HTTP API and parameter explanation are relevant but could be slightly more integrated. Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to explain return values. However, with no annotations, 0% schema description coverage, and multiple sibling tools, the description is somewhat incomplete—it lacks usage guidelines and behavioral details. It's adequate for a simple query tool but leaves gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'member_id' is a 'Coffee Company会员ID' (Coffee Company member ID), which clarifies the parameter's purpose beyond the schema's generic 'Member Id' title. Since there's only one parameter, this is sufficient for a high score, though it doesn't detail format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '查询会员的优惠券和权益券列表' (Query member's coupon and benefit voucher list). It specifies the verb (query/list) and resource (member's coupons and benefit vouchers). However, it doesn't explicitly differentiate from sibling tools like 'coupon_query', 'equity_query', or 'member_benefits', which appear related.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the HTTP API endpoint but doesn't explain context, prerequisites, or exclusions. Given sibling tools like 'coupon_query' and 'equity_query', there's no indication of how this tool differs or when it's preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the HTTP API endpoint but doesn't describe what the tool returns, error conditions, rate limits, authentication needs, or whether it's read-only or has side effects. For a query tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose followed by parameter details. The HTTP API reference is useful but could be more integrated. The structure is clear with bullet-like parameter explanations, though minor improvements in flow could enhance readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and 3 parameters with 0% schema coverage, the description is moderately complete. It covers parameter semantics well but lacks behavioral context and usage guidelines. For a query tool with output schema, it's adequate but has clear gaps in guiding the agent on when and how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the input schema, which has 0% description coverage. It explains that 'mobile' uses fuzzy matching (e.g., '138****1234'), clarifies that 'open_id' is from third-party platforms, and specifies 'member_id' is for Coffee Company. This compensates well for the schema's lack of descriptions, though it doesn't detail format constraints or provide examples beyond the mobile hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '查询Coffee Company会员信息' (query Coffee Company member information). It specifies the resource (member information) and the action (query), though it doesn't explicitly distinguish this tool from sibling tools like 'member_benefit_list' or 'member_tier'. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lists the parameters but doesn't explain scenarios where this query tool is preferred over other member-related tools like 'member_benefit_list' or 'member_tier'. There's no mention of prerequisites, constraints, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the HTTP endpoint (POST /crmadapter/account/memberTier), it doesn't describe authentication requirements, rate limits, error responses, or whether this is a read-only operation. The description doesn't explain what happens with invalid member_id values or whether the operation has 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with purpose statement first, followed by API endpoint, then parameter documentation. Each sentence serves a clear purpose. However, the Chinese-to-English code comment style creates minor redundancy, and the parameter documentation could be more integrated with the main description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which presumably describes the return structure), the description doesn't need to detail return values. However, for a tool with no annotations and a single parameter, the description adequately covers the basic purpose and parameter meaning. It lacks important behavioral context like authentication requirements and error handling that would be needed for robust agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents the single parameter (member_id) with a clear explanation: 'Coffee Company会员ID' (Coffee Company member ID). With 0% schema description coverage and only one parameter, this provides essential semantic context that the schema lacks. The description fully compensates for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '查询会员等级详情' (query member tier details) with specific outputs listed (current stars, tier validity period, gap to next level). It distinguishes itself from siblings like member_query (likely general member info) by focusing specifically on tier details. However, it doesn't explicitly contrast with member_benefit_list or member_benefits which might overlap in membership context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when this tool is appropriate compared to member_query (which might include tier info) or member_benefit_list (which might relate to tier benefits). There's no discussion of prerequisites, error conditions, or typical usage patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the HTTP API endpoint (POST /cashier/payQuery) and status codes (0=支付中, 1=支付成功, 2=支付失败), which adds some context. However, it doesn't describe error handling, rate limits, authentication needs, or what happens if the pay_token is invalid. For a query tool with zero annotation coverage, this leaves significant gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. The status code explanation and parameter details are efficiently presented. However, the inclusion of the HTTP API endpoint might be slightly extraneous if not critical for agent usage, but it doesn't significantly detract from conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, query operation) and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the purpose, parameter semantics, and status codes. The main gap is the lack of behavioral details like error handling or auth requirements, but for a simple status query tool, this is partially mitigated by the output schema and straightforward use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly defines the single parameter 'pay_token' as '支付令牌（收银下单接口返回的 payToken）' (payment token returned by the cashier order placement interface). With 0% schema description coverage (the schema only provides a title 'Pay Token' and type 'string'), the description fully compensates by explaining the parameter's origin and purpose, adding meaningful semantics beyond the basic schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as '查询支付状态' (query payment status) with specific context about it being for '收银台下单后的支付结果' (payment results after cashier order placement). It distinguishes itself from siblings by focusing on payment status queries rather than assets, coupons, equity, or member operations. However, it doesn't explicitly contrast with potential payment-related siblings that might not exist in this list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying '收银台下单后的支付结果' (after cashier order placement) and mentions the pay_token comes from '收银下单接口' (cashier order placement interface). However, it doesn't provide explicit guidance on when to use this tool versus alternatives (none of the siblings appear to be direct alternatives), nor does it state when not to use it or mention any prerequisites beyond having the pay_token.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the HTTP method (POST) and status code meanings (0-3), which adds valuable behavioral context beyond basic querying. However, it lacks details on error handling, rate limits, authentication needs, or response format, leaving gaps for a tool with mutation potential (POST).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose in the first sentence. The status explanations and HTTP API note are relevant additions. However, the structure could be improved by separating usage guidelines or parameter details more clearly, and some redundancy exists in stating the tool name in the Args section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no annotations, but with output schema), the description is reasonably complete. It covers the purpose, parameter semantics, and behavioral aspects like status codes. The presence of an output schema reduces the need to explain return values. Minor gaps include lack of error handling or sibling tool differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by specifying 'member_id' as 'Coffee Company会员ID' (Coffee Company member ID), clarifying the parameter's context and format. Since there's only one parameter, this is sufficient to elevate the score above baseline, though it doesn't detail validation rules or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '查询会员 8 项权益状态' (query member's 8 benefit statuses) with specific examples like '新人礼' (newcomer gift) and '生日奖励' (birthday reward). It distinguishes from siblings like 'member_benefit_list' by focusing on status query rather than listing. However, it doesn't explicitly contrast with 'equity_detail' or 'equity_query', leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'member_benefit_list', 'equity_detail', or 'equity_query'. The description mentions the HTTP API endpoint but doesn't provide context about prerequisites, typical use cases, or comparisons with sibling tools. Usage is implied through the query focus but not clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the HTTP API endpoint (POST /coupon/detail) and explains coupon status codes (4=unused, 10=used, 20=expired, 30=voided), which adds useful behavioral context. However, it doesn't mention authentication requirements, rate limits, error conditions, or whether this is a read-only operation (though '查询' implies querying).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose and returned fields. The API endpoint and status code explanations are relevant additions. The parameter documentation is concise with an example. No wasted sentences, though the structure could be slightly more polished (e.g., separating status codes into a bullet list).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which handles return values), no annotations, and a simple single-parameter input, the description is reasonably complete. It explains what the tool does, documents the parameter with an example, provides status code mappings, and mentions the API endpoint. For a read-oriented detail tool, this covers most essential context, though it could benefit from mentioning authentication or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description compensates well. It explains the single parameter 'coupon_code' with a clear example ('如 "CC20260301A001"') and specifies it's required. Since there's only one parameter and the description fully documents it, this exceeds the baseline of 3 for high schema coverage scenarios.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '查询单张券码的详细信息' (query detailed information of a single coupon code) and lists specific fields returned (status, face value, validity period, redemption count). It distinguishes from sibling 'coupon_query' by focusing on a single coupon rather than a list/query operation. However, it doesn't explicitly contrast with 'equity_detail' or other detail tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying it's for querying '单张券码' (single coupon code), suggesting it should be used when you have a specific coupon code to examine. However, it doesn't provide explicit guidance on when to use this versus 'coupon_query' (likely for bulk/search operations) or other sibling tools, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![coffee-mcp MCP server](https://glama.ai/mcp/servers/sawzhang/coffee-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sawzhang/coffee-mcp)

Score Badge

Copy to your README.md:

[![coffee-mcp MCP server](https://glama.ai/mcp/servers/sawzhang/coffee-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sawzhang/coffee-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sawzhang/coffee-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server