get_schedule_calendar
Query a GS cleaning robot's monthly schedule by supplying its serial number and target year-month.
Instructions
查询月度排班 / Get schedule calendar
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| robot_sn | Yes | ||
| year_month | Yes |
Query a GS cleaning robot's monthly schedule by supplying its serial number and target year-month.
查询月度排班 / Get schedule calendar
| Name | Required | Description | Default |
|---|---|---|---|
| robot_sn | Yes | ||
| year_month | Yes |
Changes observed during successful MCP inspections.
v0.4.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations and no output schema, so the description carries the full behavioral burden, yet it discloses nothing about return format, permissions, pagination, or whether the data is read-only. Only the implicit 'monthly' scope hints at behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short phrases with no wasted words, but this is under-specification rather than conciseness — it omits nearly everything an agent needs. Brevity here costs clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and 0% parameter documentation, the definition is far too thin for a tool requiring two mandatory inputs. It should at minimum describe the month format and what a schedule calendar returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and both parameters (robot_sn, year_month) are undocumented in the schema. The description's 'monthly' hints that year_month matters but gives no format (e.g. '2024-05') or semantics for robot_sn, so it fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The bilingual description states a verb ('Get'/'查询') and a resource ('schedule calendar'/'月度排班'), which is more than a tautology. However, it does not distinguish this tool from the many schedule siblings (get_schedule, list_schedules, get_schedule_pre_tasks), so an agent cannot tell which one it needs without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisite conditions, and no mention of any alternative. The word 'monthly' implies a month-scoped view but the description never says when to prefer this over get_schedule or list_schedules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.