Skip to main content
Glama
cfrs2005

GS Robot MCP Server

by cfrs2005

list_schedule_pre_tasks

Retrieve the daily pre-tasks scheduled for a GS cleaning robot by robot serial number and date. Use it to check upcoming preparatory tasks before execution.

Instructions

查询每日预任务 / List schedule pre-tasks

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYes
robot_snYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.4.1

TDQS

C2.4/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no indication of return shape, ordering, pagination, or whether results are scoped to one robot/date. The imperative "List" weakly implies a read-only operation, but that is the only behavioral signal present.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short bilingual line with no padding, so it is not verbose. But brevity here reflects under-specification rather than front-loaded efficiency — there is no structure or detail to be concise about.

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?

With two required parameters, zero schema coverage, no output schema, and no annotations, the definition is far too thin to let an agent call this correctly. It does not explain what the returned entries are, how they relate to a schedule, or what formats the required inputs accept.

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% and neither parameter has a description in the schema. The description adds no meaning for "date" or "robot_sn" beyond the hint in "每日" that the date is day-scoped; the expected date format and the role of the serial number are entirely unstated.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a verb ("List") and a resource ("schedule pre-tasks"), so the general operation is identifiable. However, "预任务 / pre-tasks" is undefined domain jargon, and nothing distinguishes this tool from siblings such as list_schedules, get_schedule_calendar, or list_task_definitions. An agent can guess the surface meaning but not the precise scope.

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?

There is no when-to-use guidance, no condition selecting this tool over list_schedules or get_schedule, and no mention of prerequisites. The agent is left to infer everything from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.