Meiju MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| meiju_loginA | Start/reuse a local login page. Show login_url to the human; never request phone/OTP in chat. Does not itself send SMS or contact Meiju. An existing login is reused. |
| meiju_login_statusA | Check whether the human has completed local login. Returns no phone, code or token. |
| meiju_logoutA | Forget this session and its saved login (if shared); invalidate pending login pages. This does not unbind devices, revoke the official app's login, or change AC settings. |
| meiju_list_devicesA | Load account devices; only the experimental AC profile supports controls. Use opaque device_id. |
| meiju_get_statusA | Read selected AC's cloud status. Missing fields stay unknown; cloud data may be cached. |
| meiju_get_capabilitiesC | Inspect the candidate protocol profile and observed fields, not guaranteed hardware capabilities. The generic profile is experimental. Unknown fields must not be treated as defaults. |
| meiju_controlA | Change only requested fields on an account-owned AC; at least one setting is required. Power is an explicit boolean. Mode/fan/temperature never implicitly turn power on. Temperature uses the candidate 17–30°C / 0.5°C client policy. Checks membership and fresh state before one write, then independently reads back. Never auto-retry an uncertain outcome. A matching cloud readback does not prove physical execution. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
The login trio (login/login_status/logout) and the AC tools (list_devices/get_status/get_capabilities/control) form distinct clusters, and descriptions clarify intent. The only mild overlap is between get_status (cloud state) and get_capabilities (protocol profile), but the descriptions distinguish live state from capability probing well enough.
All tools share a predictable meiju_ prefix and snake_case verb_noun pattern (login_status, list_devices, get_status, get_capabilities). The lone deviation is meiju_control, a bare verb without a noun, though it remains readable and unambiguous.
Seven tools is well-scoped for a focused smart-home AC server: full login lifecycle, device enumeration, status read, capability inspection, and a single write tool. Nothing feels redundant or padded.
The surface covers the core lifecycle—authenticate, discover devices, read status/capabilities, and control settings. Minor gaps exist around scheduling, scenes, or multi-device/batch operations, and only one experimental AC profile supports writes, but agent workflows are not blocked.