Skip to main content
Glama
cxOrz

meican-mcp

by cxOrz

meican_place_order

Place a meal order with selected dishes, quantity, target time, and pickup address. Dry-run mode previews the request without applying charges.

Instructions

Place a meal order. DESTRUCTIVE: this may charge the user or consume an organization subsidy. ALWAYS confirm dish names, counts, total price, target time, and pickup address with the user BEFORE calling this. Set dry_run: true first to inspect the payload without submitting.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dishesYesItems to order. One entry per dish; use `count` for quantity.
dry_runNoIf true, return the prepared request body without submitting.
namespaceNoMeican namespace for the user's organization or site. Only meican_whoami uses this to scope organization info and pickup addresses; other tools ignore it.
target_timeYes
access_tokenNoOptional Meican access token (cookie 'sat' on www.meican.com). If omitted, the server reads MEICAN_ACCESS_TOKEN from its environment.
refresh_tokenNoOptional Meican refresh token (cookie 'srt'). If omitted, the server reads MEICAN_REFRESH_TOKEN from its environment. On HTTP 401 the server refreshes once and returns the rotated pair in `_rotation`; persist it before the next call.
tab_unique_idYes
address_remarkNoFree-form note for the address.
address_unique_idYesPickup point. Get from `meican_whoami.suggested_default_address.unique_id` or the user's stored preference.
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.

Install Server

Other Tools

Latest Blog Posts

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