meican-mcp

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool has a clearly distinct purpose: cancel, list tabs, list orders, list restaurants, place order, show menu, show order details, and look up user info. No two tools have overlapping functionality.
Naming Consistency5/5
All tools follow the consistent pattern 'meican_verb_noun' with snake_case, making it easy to predict tool names and understand their actions.
Tool Count5/5
8 tools is appropriate for a meal ordering service, covering essential actions without being overwhelming or too sparse.
Completeness4/5
The set covers the full ordering lifecycle: browsing sessions, restaurants, menus, placing orders, viewing orders, and canceling. A minor gap is the lack of an update/modify order tool, but core workflows are well-supported.
Average 4.1/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 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
This repository is licensed under MIT License.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly notes the destructive nature ('this removes the order'), but without annotations, it should also disclose potential side effects, authorization requirements, or failure conditions. The missing output schema leaves the return behavior ambiguous.
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 highly concise, using only three short sentences to convey purpose, destructiveness, and usage caution. It front-loads the essential information without unnecessary detail.
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?
For a tool with 5 parameters, 1 required, and no output schema, the description is somewhat incomplete. It explains the core action and a key usage constraint but omits response details and the meaning of parameters like 'type', reducing overall completeness.
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 description adds no parameter-specific information beyond what the input schema provides. The required 'order_unique_id' parameter lacks a schema description, and the tool description does not clarify its meaning or format. Schema coverage is 60%, so the description should compensate but fails to do so.
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 'Cancel a meal order' with a specific verb and object, and the 'DESTRUCTIVE' warning reinforces the action. It distinctly differentiates from sibling tools like meican_list_orders and meican_place_order.
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 includes an explicit instruction to 'ALWAYS confirm with the user before calling,' providing clear context for when to invoke the tool. However, it does not mention when not to use it or suggest alternatives for handling cancellation scenarios.
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 provided. Description adds context about returned fields and expected statuses, but does not explicitly state read-only nature, error cases, or authentication behavior beyond schema. Adequate but not fully transparent.
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?
Two sentences, no waste. Front-loaded with purpose and key details. Every word 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?
No output schema, so description carries burden. It lists what is shown but not the structure or error handling. Adequate for a simple status check but not fully detailed.
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?
Schema coverage is 100% with detailed descriptions. The description adds minimal value for order_unique_id by noting its source (meican_place_order or meican_list_orders). Baseline 3 appropriate.
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?
Clearly states it shows full status of one order by uniqueId, listing specific fields (pickup location, pay status, dishes). Distinct from sibling tools like meican_list_orders (list) and meican_place_order (create).
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 'Use after placing an order to confirm it succeeded' and provides expected status values. While it doesn't mention when not to use, the context is clear.
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?
Without annotations, the description carries the burden. It indicates a read operation ('List') but does not explicitly state it is non-destructive or detail authentication behavior. The lack of side-effect disclosure is acceptable for a simple list tool, but more context could be helpful.
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?
Two sentences, front-loaded with purpose and a key usage guideline. No wasted words, effectively communicates the tool's role.
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 list tool with 4 parameters and no output schema, the description covers the essential purpose and a critical usage note. It could mention output format or pagination but is adequate given the tool's simplicity.
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 input schema covers all 4 parameters with descriptions (100% coverage). The description does not add meaning beyond what the schema provides, so baseline score 3 applies.
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 lists the current user's orders for a date plus unpaid items. The verb 'List' and resource 'existing Meican orders' are specific. It distinguishes from siblings like 'meican_show_order' (single order) and 'meican_place_order' (placing orders).
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 advises calling this before 'meican_place_order' to avoid duplicates, providing clear usage context. However, it does not mention when not to use it or list alternatives like 'meican_show_order'.
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 provided, so description carries burden. It states it's a read operation returning restaurant IDs and names, but does not disclose authentication flow, error cases, or side effects. Schema descriptions cover token parameters, but description adds little beyond that.
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?
Two sentences, no extraneous content. Front-loads core purpose and critical usage guidance.
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 5 parameters (2 required) and no output schema, description covers key outputs and prerequisite tool call. Could be improved by noting that a prior call to meican_list_meal_tabs is required, but the instruction to 'get the args' implies that.
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?
Schema description coverage is 100%, so baseline 3. The description repeats the schema's hints about meican_list_meal_tabs, adding no new semantic value for parameters.
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?
Clearly specifies 'List restaurants serving in one meal session' with return fields, distinct from sibling tools that focus on orders, meals, or menus.
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 directs agent to get arguments from meican_list_meal_tabs, guiding correct invocation order. Does not mention when to avoid or alternatives, but context suggests it's the natural next step.
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 that results are grouped by section and that dish_id values are needed, but does not describe other behavioral traits such as read-only nature, authentication requirements, or side effects. The description adds some value but lacks comprehensive transparency.
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: two sentences, front-loaded with purpose and a key usage tip. No extraneous information.
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 6 parameters and no output schema, the description provides adequate context: purpose, output structure (dishes grouped by section), and a usage hint. However, it could elaborate on what 'meal session' means or the target_time parameter's role. Still, it covers the essential points well.
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?
Schema description coverage is 67%, meaning the schema already documents most parameters. The description does not add extra meaning beyond what is in the schema; it only provides a usage hint about dish_id. With moderate coverage, a baseline of 3 is appropriate.
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 ('Show') and resource ('one restaurant's full menu for a meal session') and distinguishes from siblings by noting that dish_id values from this output are needed for placing an order.
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 indicates when to use the tool ('You need `dish_id` values from here to place an order'), implying it should be used before ordering. However, it does not explicitly state when not to use it or mention alternatives, though sibling context provides sufficient differentiation.
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 carries full burden. It discloses that each tab has a deadline (target_time) and that existing_order indicates a prior order. It advises to surface existing orders instead of placing duplicates. No destructive behavior is implied; the tool is read-only. The description adequately informs agent behavior.
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?
Three sentences, each earning its place: first defines purpose, second explains key fields and usage, third gives ordering guidance. Front-loaded with the core action. No verbose or redundant 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?
No output schema exists, so the description should outline return value structure. It mentions tab_unique_id and target_time, implying a list of objects, but does not fully describe the response format (e.g., array, additional fields like existing_order). However, the core information needed for a simple list tool is present.
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?
Schema coverage is 100%, so baseline is 3. The description adds context that target_time is the order deadline and should be passed verbatim, but this is not substantial beyond the schema's own descriptions. No additional parameter meaning is provided.
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?
Clearly states the tool lists meal sessions (餐次) for a given date, with specific examples like 午餐, 晚餐. Distinguishes itself from sibling tools by positioning as the first step for ordering or viewing orders, with explicit mention of tab_unique_id and target_time for use in subsequent tools.
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 'Use this FIRST when the user wants to order or view orders for a day.' Provides guidance on handling existing_order to avoid duplicates. While it doesn't list alternatives, the context is clear enough for an agent to decide when to invoke this tool.
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 carries the full burden. It explicitly labels the tool as 'DESTRUCTIVE' and warns that it may charge the user or consume a subsidy. This is a key behavioral disclosure. However, it could mention more about error states or confirmation behavior, but the warning is sufficient.
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 extremely concise: two sentences front-load the purpose and immediate warnings. Every sentence adds essential guidance without redundancy.
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 description focuses on input behavior and safety, but does not describe the return value or error handling. Since there is no output schema, the agent lacks information about what the tool returns upon success or failure. For a destructive tool, this is a notable gap.
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?
Schema coverage is 78%, so most parameters already have descriptions in the schema. The description does not add new semantic information beyond the schema. It indirectly references parameters by naming dish names, counts, etc., but does not elaborate on them.
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 'Place a meal order', specifying the verb and resource. It distinguishes from sibling tools like meican_cancel_order, meican_list_orders, etc., which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to confirm dish names, counts, total price, target time, and pickup address with the user before calling, and to set dry_run: true first to inspect payload. This provides clear guidance on when and how to use the tool safely.
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 carries the burden; it discloses token refresh behavior on HTTP 401 and that the server returns rotated tokens. It implicitly indicates a read operation ("Look up"), but does not explicitly state there are no side effects. The token rotation detail adds useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loaded with the main purpose, and every sentence adds essential information (purpose, follow-up action, parameter notes). No extraneous 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?
Given the tool has no output schema and three parameters, the description covers the key outputs (org info, all addresses, `suggested_default_address`) and token refresh behavior. It lacks explicit error handling or full output structure, but the stated information suffices for a lookup 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?
All three parameters are described in the schema (100% coverage), but the description adds value beyond the schema: it explains that `namespace` is only used by this tool, that `access_token` and `refresh_token` fall back to environment variables, and that refresh tokens may be rotated. This extra context helps the agent use parameters correctly.
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 looks up the user's organization info and all delivery addresses, and identifies the `suggested_default_address`. It distinguishes itself from sibling tools by focusing on user profile and address discovery, which is unique among the siblings like `meican_place_order` or `meican_list_restaurants`.
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 advises calling this tool once per user to obtain the `suggested_default_address` and pass it to `meican_place_order`. This provides clear usage context and a follow-up action, though it does not explicitly state when not to use it or list alternatives.
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:

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

Score Badge

Copy to your README.md:

[![meican-mcp MCP server](https://glama.ai/mcp/servers/cxOrz/meican-mcp/badges/score.svg)](https://glama.ai/mcp/servers/cxOrz/meican-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/cxOrz/meican-mcp'

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