mcp-drink-main

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a distinct purpose: listing orders, finding duplicates by name, searching all duplicates, getting duplicate statistics, updating/deleting by ID or by name, fetching the menu, and placing orders. The update and delete pairs are clearly differentiated by the identifier type (doc_id vs. name), and the duplicate tools are distinguished by scope.
Naming Consistency4/5
Most tools follow a verb_noun pattern (e.g., list_recent_orders, get_menu, place_drink_order), but there are minor inconsistencies such as using both 'find_' and 'search_' for similar duplicate operations, and 'update_drink_order' versus 'update_order_by_name' where the object naming varies. Overall the pattern is readable but not perfectly uniform.
Tool Count5/5
With 10 tools, the server is well-scoped for the drink ordering and duplicate-detection domain. Each tool serves a necessary function, and the count is neither too sparse nor overwhelming.
Completeness5/5
The tool surface covers the full CRUD lifecycle for orders (place, list, update, delete), includes menu retrieval, and provides comprehensive duplicate detection and statistics. No obvious gaps exist for the intended functionality.
Average 3.8/5 across 10 of 10 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 41 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
There are no annotations, so the description alone must convey behavioral traits. It only states that it deletes an order; it does not disclose whether the action is permanent, requires permissions, or what happens if the ID does not exist. This is a significant gap for a destructive operation.
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 very brief and to the point, with the main purpose stated first and the parameter defined immediately after. It wastes no words, though it is minimal and could benefit from more context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and usage guidance, the description is incomplete. It covers the basic purpose and parameter but omits when to use it, behavioral consequences, and error handling, leaving important gaps for a destructive operation.
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 explains doc_id as 'the ID of the order to delete,' which adds meaning beyond the bare schema definition of a string. Since there is only one parameter and it is clearly defined, it compensates well for the lack of schema descriptions.
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 it deletes a specified drink order, and the inclusion of doc_id indicates the identifier used. It is specific in verb and resource, though it does not explicitly contrast with delete_order_by_name, making the distinction implicit via the parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the sibling delete_order_by_name or other tools. The description does not mention any conditions, alternatives, or prerequisites for using this deletion method.
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 must carry the full burden of behavioral disclosure. It only states 'delete orders' without mentioning irreversibility, whether multiple orders are affected, permission requirements, or any side effects. The destructive nature is implied but not explicitly disclosed.
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 a single, clear sentence. It is concise and front-loaded, effectively conveying the core action. It does not waste words, though it could be expanded with important details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, the description is incomplete. It does not explain what happens to the deleted orders, whether it deletes all orders matching the name or just one, or any error conditions. The output schema may cover return values, but the description offers no behavioral or safety context. It is minimally viable but lacks necessary depth.
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 schema has 0% description coverage, but the description does add some semantic meaning: 'by name' clarifies that the 'name' parameter is the matching criterion for deletion. However, it does not specify matching behavior (exact, partial, case-insensitive) or whether it deletes all matches, so it only partially compensates for the lack of schema 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 action (delete) and resource (orders) with a selection criterion (by name). It is specific and understandable, but it does not explicitly differentiate from sibling tools like delete_drink_order, so it lacks the sibling distinction required for a 5.
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 guidance is provided on when to use this tool versus alternatives such as update_order_by_name or delete_drink_order. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage entirely from the tool name and description.
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, the description carries the full burden. It does disclose that only the provided fields are updated (partial update behavior) and that doc_id is required. However, it does not mention what happens if the order is not found, whether changes are reversible, or what the response looks like, which are significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and uses a clear bullet list to highlight doc_id and the partial-update guideline. Every sentence provides value, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and zero parameter documentation in the schema, the description is incomplete. It does not explain return values, error cases, or how this tool differs from update_order_by_name beyond the use of ID. Relying on 'same as the ordering tool' for most parameters weakens independence. Overall, the tool is not fully self-contained for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (schema coverage 0%), so the description must compensate. It explains doc_id ('unique order ID obtained from the list') but refers to all other parameters as 'same as the ordering tool' without specifying their meanings. For a tool with five parameters, this leaves the semantics of name, spec, topping, and drink_name largely unexplained and dependent on another tool's 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 'Modify an existing order' with a specific verb and resource. It also provides a usage condition ('when the user provides an order ID and requests changes') and distinguishes itself from siblings by requiring doc_id, though it does not explicitly name the alternative update_order_by_name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use when user provides order ID and requests changes.' It also gives guidance on partial updates ('only input the parts that need to be modified'), which clarifies usage. However, it does not explicitly mention when not to use it (e.g., when only name is known), so it lacks an explicit exclusion.
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, the description carries the behavioral disclosure burden. It adds useful behavior about optional parameters (None means 'keep unchanged'), but it does not disclose other important traits such as behavior when no matching name is found, whether it updates one or multiple orders, or error handling. This is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first gives the purpose, the second adds crucial behavior about optional parameters. It is concise, front-loaded, and every sentence earns its place.
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?
The tool has 4 parameters, no annotations, but an output schema exists. The description covers the core behavior and the None semantics, but lacks details about edge cases (e.g., multiple matches), which fields are updatable, and how to use 'spec'. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 explains the general optionality semantics (None means no change), but it does not explain what each parameter (spec, topping, drink_name) actually represents. The parameter meanings remain largely ambiguous, especially 'spec', leaving the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'modify order content based on name'. This is a specific verb+resource+scope (by name), and it distinguishes from siblings like update_drink_order (likely by ID) and delete_order_by_name (delete vs update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool, especially the optional parameters to handle 'the rest unchanged' scenario. While it doesn't explicitly exclude alternatives, the naming and phrasing imply using it when you want to update an order by customer name, which differentiates it from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 transparently explains the behavior: finds all orders under the name, identifies duplicates based on same drink/spec/add-ons, and shows duplicate count and timestamps. It implies read-only via '搜尋' and '找出', though it does not explicitly state no modifications occur.
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 well-structured with an emoji-led summary, trigger examples, parameter explanation, and a function list. It is not overly verbose and front-loads the purpose, though the trigger examples and function list add some length. No wasted words.
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?
The tool is simple (1 parameter, no nested objects) and has an output schema, so the description does not need to explain return values. It covers the operation logic, duplicate matching criteria, and output elements. It lacks explicit alternative tool mentions, but overall the description is complete for its complexity.
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 only defines 'name' as a string with no description, so schema coverage is 0%. The description compensates by stating 'name: 要查詢的人名', giving meaning and context to the parameter. It does not mention input format nuances like exact matching, but it sufficiently explains the purpose.
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 it searches for duplicate order data of a specific person using the verb '搜尋' (search) and the resource '特定人物的重複訂單資料'. It distinguishes from sibling tools like search_all_duplicates by scoping to a specific person, though it does not explicitly mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit trigger scenarios in Chinese: '當使用者詢問「搜尋個人有重複的資料」、「某人有重複訂單」時，請呼叫此工具'. This tells when to use the tool, but it does not mention when not to use it or compare with sibling tools like search_all_duplicates.
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?
No annotations are provided, so the description carries the full burden. It discloses the main behavior—scanning all orders, identifying duplicates, and showing count statistics—which implies a read-only analysis. However, it does not explicitly state that no data is modified, nor does it mention performance, permissions, or limitations.
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. The trigger phrases are useful for usage guidance. The bullet list slightly repeats the first sentence but remains concise and scannable, so no significant waste.
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 no parameters, an output schema exists, and the operation is a simple global scan, the description covers the essential context: what it does, when to use it, and what output to expect (duplicate count statistics). Minor gaps include lack of explicit differentiation from sibling tools, but overall it is complete enough for a no-argument scan tool.
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 tool has zero parameters and the schema is empty with 100% coverage. The description does not need to elaborate on parameters; the baseline for no-parameter tools is 4, and nothing in the description contradicts or requires additional parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans all orders and finds all people with duplicate orders (掃描全部訂單，找出所有有重複訂單的人物). It uses a specific verb, resource, and scope, and distinguishes itself from sibling find_duplicate_orders_by_name by emphasizing the global '全部' and '全局搜尋重複' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to call it: when the user asks for global duplicate search or who has duplicate orders (「全局搜尋重複」、「誰有重複訂單」). It provides clear context and trigger phrases, but it does not explicitly mention when not to use it or name alternative tools like find_duplicate_orders_by_name.
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?
No annotations are provided, so the description must carry the transparency burden. It describes what the tool does (computes proportions, shows popular items, gives suggestions) but does not explicitly state whether it is read-only, has side effects, or its data scope. The name implies a read operation, but explicit disclosure would be stronger.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a trigger condition, and a bulleted list of features. It front-loads the core purpose and every sentence earns its place without redundancy.
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?
For a tool with zero parameters and an output schema, the description provides sufficient context: trigger conditions and expected functionality. It could specify whether statistics are system-wide or scoped, but the simplicity of the tool and existence of an output schema make the current description adequately complete.
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 input schema has zero parameters, so the description does not need to explain parameter meanings. The baseline for 0 params is 4, and the description appropriately avoids unnecessary parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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: to get statistical information on duplicate orders. It lists specific capabilities (calculate duplicate rate, show popular duplicates, provide suggestions) and distinguishes itself from sibling tools like find_duplicate_orders_by_name or search_all_duplicates by focusing on aggregate statistics rather than individual duplicates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names trigger phrases ('重複訂單統計', '重複率') that should lead to this tool, providing clear usage contexts. It does not mention when not to use it or name alternative tools, but the trigger guidance is sufficient for basic differentiation.
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?
Since no annotations are provided, the description must carry the full burden. It implies a read-only listing operation and mentions it helps confirm IDs before mutations, but it does not explicitly state whether the tool is read-only, nor does it disclose any side effects, permissions, or return format limitations. The information is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence front-loads the action and output fields; the second adds a practical usage note. There is zero wasted text.
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?
For a simple no-parameter list tool with no output schema, the description adequately explains what is returned (ID, name, items) and why to use it (confirm ID before mutations). It could be slightly more precise about what 'recent' means, but overall it is complete enough.
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 tool has zero parameters, so the schema fully covers parameter semantics (trivially). The description does not need to describe parameters. Per the rubric, 0 params baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb '列出' (list) and the resource '最近的所有訂單資訊' (all recent order information), specifying the fields included (ID, name, items). It distinguishes itself from sibling tools like update/delete/duplicate search by being a simple listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call this tool before deleting or modifying an order to confirm the ID, providing a clear when-to-use scenario. However, it does not explicitly mention when not to use it or name alternative tools, so it falls slightly short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 discloses the read-only nature ('查詢') but does not describe the return format or response structure. The presence of an output schema partially mitigates this, but the description itself adds minimal behavioral context beyond the query intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the key information and usage condition. Every sentence earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple menu query with no parameters and an existing output schema, the description covers what the tool does and when to use it. The output schema handles return values, so the description is complete for its purpose.
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 tool has zero parameters, so the description does not need to explain any. Schema coverage is 100% vacuously. Baseline for 0 params is 4, and no additional semantic details are necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '查詢' (query) and identifies the resource: beverage items, prices, and toppings. It clearly distinguishes from sibling tools which handle order management, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to invoke the tool (when users ask about available drinks, prices, menu, or add-ons). It does not mention exclusions or alternatives, but no alternative menu tool exists among siblings, so the guidance is clear though not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: drink_name is auto-matched to the closest item, spec must include sugar/ice and missing info should be proactively asked, and topping defaults to '無'. This adds meaningful context beyond the bare schema, though it does not describe the return value or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the tool's purpose, and uses a clear bullet-like structure for parameter explanations. Every sentence contributes value, with no wasted words.
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?
The description covers when to use, parameter semantics, and behavioral matching details. It omits return value or confirmation behavior, but for a simple create-order tool, the outcome is intuitive. Given no output schema exists, a brief note on the response would improve completeness, but it is already adequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description fully explains each parameter: name must be obtained, drink_name auto-matches, spec requires sweetness and ice, and topping defaults. This completely compensates for the schema's lack of semantic information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes a drink ordering tool and specifies when to call it ('當使用者表達想喝飲料或點餐時'). This distinguishes it from sibling tools that update, delete, or list orders, making its purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use the tool when the user expresses wanting a drink or to order, providing clear context. It does not mention alternatives or exclusions, but the sibling tools (update, delete, list) make the boundaries implicit, so it earns a 4 rather than a 5.
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:

[![mcp-drink-main MCP server](https://glama.ai/mcp/servers/niceheadwkt/mcp-drink-main/badges/card.svg)](https://glama.ai/mcp/servers/niceheadwkt/mcp-drink-main)

Score Badge

Copy to your README.md:

[![mcp-drink-main MCP server](https://glama.ai/mcp/servers/niceheadwkt/mcp-drink-main/badges/score.svg)](https://glama.ai/mcp/servers/niceheadwkt/mcp-drink-main)

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/niceheadwkt/mcp-drink-main'

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