이 프로젝트는 Gausium OpenAPI에 대한 브리지 역할을 하는 MCP(Model Control Protocol) 서버를 구현하여 AI 모델이나 다른 클라이언트가 표준화된 인터페이스를 통해 Gausium 로봇과 상호 작용할 수 있도록 합니다.
저장소: https://github.com/cfrs2005/mcp-gs-robot
서버는 관심사를 분리하고 유지 관리를 용이하게 하는 계층화된 아키텍처를 따릅니다.
아래 다이어그램은 AI 모델이 MCP 프로토콜을 통해 Gausium 로봇과 상호 작용하는 방식을 보여줍니다.
Related MCP server: Eufy RoboVac MCP Server
현재 서버는 MCP 도구로서 다음과 같은 기능을 지원합니다.
list_robots : API 키를 통해 접근 가능한 로봇을 나열합니다. (기반: List Robots API )
get_robot_status : 일련번호를 기준으로 특정 로봇의 자세한 상태를 가져옵니다. (기반: 로봇 상태 가져오기 API )
list_robot_task_reports : 특정 로봇의 청소 작업 보고서를 검색하며, 시간 필터링을 선택적으로 적용할 수 있습니다. ( List Robot Task Reports API 기반)
list_robot_maps : 특정 로봇과 관련된 지도를 나열합니다. ( List Robot Maps API 기반)
이 프로젝트는 Python 모범 사례를 기반으로 한 구조화된 레이아웃을 따릅니다.
지엑스피1
src/gs_openapi/config.py : 기본 URL, API 경로, 환경 변수 이름을 포함합니다.
src/gs_openapi/auth/token_manager.py : OAuth 토큰 획득 및 갱신을 관리합니다.
src/gs_openapi/api/ : httpx 사용하여 Gausium OpenAPI 엔드포인트를 직접 호출하는 기능이 있는 모듈( robots.py , maps.py )이 포함되어 있습니다.
src/gs_openapi/mcp/gausium_mcp.py : API 호출과 토큰 관리를 통합하는 GausiumMCP 클래스를 정의합니다.
main.py : GausiumMCP 초기화하고, @mcp.tool() 사용하여 API 기능을 MCP 도구로 등록하고, 기본 로깅을 구성하고, mcp.run() 사용하여 서버를 시작합니다.
저장소를 복제합니다.
git clone https://github.com/cfrs2005/mcp-gs-robot.git
cd mcp-gs-robotuv 사용하여 가상 환경을 만들고 활성화합니다.
uv venv
source .venv/bin/activate # On Windows use `.venv\Scripts\activate`uv 사용하여 종속성을 설치합니다.
uv pip install -r requirements.txt
# Or, if you prefer adding specific core packages:
# uv add httpx "mcp[cli]"자격 증명 구성: 애플리케이션은 Gausium API 자격 증명이 환경 변수로 설정되기를 기대합니다.
GS_CLIENT_ID : Gausium 애플리케이션 클라이언트 ID입니다.
GS_CLIENT_SECRET : Gausium 애플리케이션 클라이언트 비밀번호입니다.
GS_OPEN_ACCESS_KEY : Gausium OpenAPI 액세스 키.
쉘에서 직접 설정할 수 있습니다:
export GS_CLIENT_ID="your_client_id"
export GS_CLIENT_SECRET="your_client_secret"
export GS_OPEN_ACCESS_KEY="your_access_key"(또는 개발용으로 src/gs_openapi/config.py 수정하지만 자격 증명은 커밋하지 마세요 ).
서버를 실행합니다:
python main.py기본적으로 이 명령은 http://0.0.0.0:8000 에서 SSE 전송을 사용하여 서버를 시작합니다. 필요한 경우 stdio 전송을 사용하도록 main.py 수정할 수 있습니다.
서버가 실행되면 MCP 클라이언트(Cursor나 다른 호환 도구)가 적절한 전송(SSE 또는 stdio)을 통해 서버에 연결하여 정의된 도구를 활용할 수 있습니다.
다음은 Cursor가 MCP 서버와 상호 작용하는 방식의 예입니다.
디버깅 정보를 확인하기 위해 서버 로그를 모니터링할 수 있습니다. main.py 의 기본 로깅 설정은 타임스탬프, 레벨, 소스 정보를 제공합니다.
다음은 운영 중 서버 로그 출력의 예입니다.
智能批量获取机器人状态。
自动根据机器人系列分组并选择正确的批量API。
支持混合查询M-line和S-line机器人。
Args:
serial_numbers: 机器人序列号列表
Returns:
批量状态查询结果字典
| Name | Required | Description | Default |
|---|---|---|---|
| serial_numbers | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behavior: automatic grouping by robot series and selection of correct batch API. However, it does not cover error handling, authentication needs, or rate limits, which are relevant for a batch operation.
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?
The description is concise (two sentences plus Args/Returns), front-loaded with the purpose, and contains no wasted words. The structure is clear and efficient.
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?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description provides adequate context for an AI agent to understand its purpose and basic behavior. It mentions the return type (dictionary) but omits details on the dictionary structure. Still, it is sufficiently complete for the tool's complexity.
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?
With only one parameter and 0% schema coverage, the description adds value by clarifying that 'serial_numbers' is a list of robot serial numbers. This is meaningful beyond the empty schema. Could be improved by specifying the expected type (e.g., strings) or constraints.
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 description explicitly states '智能批量获取机器人状态' (smart batch get robot statuses), clearly indicating the verb (get) and resource (robot statuses). It distinguishes from siblings like 'get_robot_status_smart' by emphasizing batch and smart grouping, and mentions support for mixed series.
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?
The description implies when to use (for batch queries, especially with mixed M-line and S-line robots) but does not explicitly state when not to use or mention alternatives like the singular 'get_robot_status_smart'. Clear context, but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a robot command.
Based on: https://developer.gs-robot.com/zh_CN/Robot%20Command%20Service/Create%20Robot%20Command
Args:
serial_number: The serial number of the target robot.
command_type: The type of command (e.g., 'START_TASK', 'PAUSE_TASK', 'STOP_TASK').
command_parameter: Optional command parameters as a dictionary.
Returns:
A dictionary containing the command creation result.
| Name | Required | Description | Default |
|---|---|---|---|
| serial_number | Yes | ||
| command_type | Yes | ||
| command_parameter | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks disclosure of behavioral traits such as whether the command is asynchronous, failure modes, or required permissions. The annotation field is empty, so the description carries full burden but only states 'Creates a robot command' without depth. The URL reference is external and not directly actionable.
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?
The description is concise at ~8 lines, with a clear structure: purpose, reference, args list, returns. It front-loads the purpose and includes only essential details. The URL adds slight noise but is brief.
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 or output schema, the description must cover all context. It specifies inputs and return type but omits command_type options, error handling, and permissions. It is adequate for a basic understanding but not fully complete for safe invocation.
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 descriptions are absent (0% coverage), so the description compensates by explaining each parameter: serial_number as robot identifier, command_type as type of command, and command_parameter as optional dictionary. This adds meaning beyond the schema's titles, especially for command_parameter.
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?
Description states 'Creates a robot command' clearly. It includes a reference URL and lists parameters, making the purpose explicit. However, it does not explicitly differentiate from sibling tools like submit_temp_site_task or execute_m_line_task_workflow, which also create robot actions, leaving some ambiguity.
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?
No guidance on when to use this tool versus alternatives. The description only defines what the tool does without context for selection. Sibling tools exist for executing tasks and submitting jobs, but no criteria are given for choosing create_robot_command over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Downloads a robot map using V1 API.
Args:
map_id: The ID of the map to download.
Returns:
A dictionary containing the map download information.
| Name | Required | Description | Default |
|---|---|---|---|
| map_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose important behavioral details such as whether the download is synchronous, file format, size limits, or authentication requirements. The agent lacks context on side effects or expected 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?
The description is brief (under 30 words) and includes an Args/Returns section for structure. However, it could be more concise by omitting the trivially obvious lines and instead providing critical details.
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?
Given no output schema, the description should clarify the return structure, but it only states 'dictionary containing the map download information,' which is ambiguous. Lacks details on error handling, file content, or further processing steps.
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?
The input schema has 100% coverage (1 parameter, map_id), but the description only repeats that it is 'The ID of the map to download' without adding meaning beyond the schema. No information on allowed values, format, or source for the ID is provided.
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 description clearly states the action (downloads) and resource (robot map) along with API version (V1). However, it does not distinguish from the sibling tool download_robot_map_v2, which likely has a different purpose or behavior.
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?
No guidance is provided on when to use this tool versus alternatives like download_robot_map_v2. There is no mention of prerequisites, scenarios, or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Downloads a robot map using V2 API.
Args:
map_id: The ID of the map to download.
Returns:
A dictionary containing the map download information.
| Name | Required | Description | Default |
|---|---|---|---|
| map_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the burden. It only mentions 'downloads' and 'returns a dictionary' without detailing side effects, permissions, or response structure.
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?
The description is short but includes unnecessary formatting like 'Args:' and 'Returns:' for a single parameter. It could be more concise without losing 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?
Given simple tool (one parameter), the description adequately states purpose and basic return type, but lacks detail on output format or behavioral context. It meets minimum viability but has gaps.
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?
The only parameter map_id is described as 'The ID of the map to download,' which adds no meaning beyond its schema title. With 0% schema description coverage, the description fails to compensate for missing parameter context.
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 description clearly states 'Downloads a robot map using V2 API,' specifying the verb and resource. It distinguishes from siblings like download_robot_map_v1 by version, though it doesn't elaborate on differences.
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?
No guidance on when to use this tool versus alternatives such as download_robot_map_v1 or upload_robot_map_v1. It lacks context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes complete M-line robot task workflow.
Automated process: Status query → Task selection → Command execution
Args:
serial_number: The serial number of the target robot.
task_selection_criteria: Optional task selection criteria.
Returns:
A dictionary containing the workflow execution result.
| Name | Required | Description | Default |
|---|---|---|---|
| serial_number | Yes | ||
| task_selection_criteria | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions an automated process but does not detail side effects, destructive potential, permissions, rate limits, or error conditions. The steps are listed but not elaborated.
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?
The description is short but includes an artificial 'Args:' and 'Returns:' section that is not standard. The process steps add some value but could be integrated more concisely.
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?
Given the tool complexity (workflow execution, 2 params, no output schema), the description lacks detail on prerequisites, outcomes, error handling, and return value shape. It is insufficient for a complete understanding.
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%, so the description carries the burden. It adds basic meaning for serial_number and task_selection_criteria, but the latter is vague ('Optional task selection criteria') without specifying valid values, format, or behavior.
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 description clearly states the tool executes a complete M-line robot task workflow, with a specific verb and resource. The name and description differentiate it from sibling S-line workflow tools, though not explicitly.
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?
No guidance on when to use this tool versus alternatives such as create_robot_command or execute_s_line_* workflows. The description only lists internal steps but does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes complete S-line robot task workflow without site information.
Automated process: Map list → Map selection → Subarea retrieval → Task building → Task submission
Args:
robot_sn: The serial number of the target robot.
task_parameters: Task parameters including map criteria and task settings.
Returns:
A dictionary containing the workflow execution result.
| Name | Required | Description | Default |
|---|---|---|---|
| robot_sn | Yes | ||
| task_parameters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description lists automation steps (Map list → Task submission) but does not disclose side effects, permissions needed, error handling, or whether the task submission is destructive. With no annotations, the description should provide more behavioral detail.
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?
The description is moderately concise, organized with steps, Args, and Returns. It could omit the step list without losing core meaning, but it remains efficient and scannable.
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?
Given no output schema and complex workflow, the description lacks details on result contents, error states, and prerequisite knowledge. It does not fully equip the agent to understand what the workflow produces or how parameters affect behavior.
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 coverage is 0%. For 'robot_sn', the description adds little beyond the schema title. For 'task_parameters', it vaguely mentions 'map criteria and task settings' but fails to specify the expected object structure or keys, leaving the agent underinformed.
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 description clearly states it executes a complete S-line robot task workflow without site information, distinguishing it from the sibling tool 'execute_s_line_site_task_workflow'. The steps list further clarifies the scope.
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?
The description implies use when site information is absent via 'without site information', but it does not explicitly contrast with the site-aware sibling or mention when-not to use. Context is clear, but exclusion guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Executes complete S-line robot task workflow with site information.
Automated process: Site info → Map selection → Subarea retrieval → Task building → Task submission
Args:
robot_id: The ID of the target robot.
task_parameters: Task parameters including map criteria and task settings.
Returns:
A dictionary containing the workflow execution result.
| Name | Required | Description | Default |
|---|---|---|---|
| robot_id | Yes | ||
| task_parameters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the sole source. It outlines the workflow steps (Site info → Map selection → Subarea retrieval → Task building → Task submission), which adds behavioral context. However, it does not disclose side effects, permissions, error handling, or whether the workflow is asynchronous.
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?
Description is relatively concise with structured sections (description, automated process, args, returns). The 'Automated process' line is informative but adds a bit of redundancy. Could be slightly tighter, but overall well-organized.
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?
Given the tool's complexity (workflow with nested parameters), the description explains the overall process and parameter roles. No output schema, but return type is stated. Sibling tools exist, and description helps differentiate. Lacks specific details on error conditions or return structure, but adequate.
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 has 0% description coverage, but description adds meaning: 'robot_id: The ID of the target robot' and 'task_parameters: Task parameters including map criteria and task settings'. This clarifies the purpose of each parameter, especially the nested object's expected contents.
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?
Description clearly states verb 'Executes' and resource 'complete S-line robot task workflow with site information'. It distinguishes from siblings like execute_s_line_no_site_task_workflow and execute_m_line_task_workflow by specifying 'S-line' and 'site information'.
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?
Description implies usage context (automated workflow with site info) but does not explicitly state when to use this tool over alternatives or provide exclusion criteria. No guidance on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generates a PNG map for M-line task report.
Args:
serial_number: The serial number of the target robot.
report_id: The ID of the task report.
Returns:
A dictionary containing the map generation result.
| Name | Required | Description | Default |
|---|---|---|---|
| serial_number | Yes | ||
| report_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior fully. It mentions generation but does not state side effects (e.g., file storage), error conditions, or the format of the returned dictionary. The return type is vague.
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?
The description is concise with a clear structure (heading plus args/returns). It avoids unnecessary text, though the brevity sacrifices completeness. Still effective for its length.
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?
Given the simplicity of 2 string parameters and no output schema, the description is incomplete. It omits the structure of the return dictionary, typical usage scenarios, and relationship to sibling tools.
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%, so the description should enrich parameter meaning. It merely rephrases the parameter names ('serial number of target robot', 'ID of the task report') without adding contextual hints like where to obtain these values.
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 description clearly states it generates a PNG map for an M-line task report, identifying the specific resource and action. While the meaning of 'M-line' may be unclear, it distinguishes this tool from sibling map and report tools.
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?
No guidance on when to use this tool versus alternatives like download_robot_map_v1/v2 or get_task_reports_smart. The description does not provide context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets map subareas information for precise area control.
Args:
map_id: The ID of the target map.
Returns:
A dictionary containing map subareas information.
| Name | Required | Description | Default |
|---|---|---|---|
| map_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states a read operation ('Gets') but does not disclose permissions, side effects, or error conditions. The return type is mentioned but not detailed.
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?
The description is short and to the point, with clear Args and Returns sections. However, it could be slightly more structured with a brief explanation of the subareas concept.
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?
Given the simple input (one string) and no output schema, the description provides the minimum viable information. It lacks details on the structure of the returned dictionary, but for a straightforward retrieval tool it is acceptable.
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 the description adds no meaning beyond the parameter name ('The ID of the target map'). It does not explain valid values, constraints, or how to obtain the map_id.
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 description clearly states it retrieves map subareas information for precise area control, which is a specific verb-resource combination. However, it does not differentiate from sibling tools like get_robot_capabilities or list_robot_maps, which also deal with map data.
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?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions, leaving the agent without direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取机器人支持的API能力。
显示该机器人支持哪些API端点和功能。
Args:
serial_number: 机器人序列号
Returns:
机器人能力信息字典
| Name | Required | Description | Default |
|---|---|---|---|
| serial_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided; the description lacks behavioral details such as read-only nature, permission requirements, or response semantics.
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?
The description is brief and front-loaded, but the 'Args' section is redundant with the schema; no extra fluff.
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 output schema, the return value is vaguely described as 'capability info dictionary' without structure or possible values, leaving the agent underinformed.
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?
The description only restates the parameter name and type ('robot serial number'), adding no value beyond the schema; schema description coverage is 0%.
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 description clearly states the tool retrieves robot API capabilities and endpoints, distinguishing it from status or command tools, though it does not explicitly differentiate from siblings.
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?
No guidance on when to use this tool versus alternatives like get_robot_status_smart or list_robot_commands; the usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the result of a specific robot command.
Args:
serial_number: The serial number of the target robot.
command_id: The ID of the command to query.
Returns:
A dictionary containing the command execution result.
| Name | Required | Description | Default |
|---|---|---|---|
| serial_number | Yes | ||
| command_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It only states 'Gets the result,' implying a read operation, but no explicit disclosure of side effects, permissions, rate limits, or other behavioral traits.
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?
Description is concise, front-loaded with main purpose, includes parameter descriptions and return type. No unnecessary words or redundancy.
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?
Given no output schema, description mentions a dictionary result but lacks details on its structure. For a simple query tool, it is minimally complete but could be more helpful with result fields.
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 coverage is 0%, so description adds meaning with brief explanations for each parameter (e.g., 'The serial number of the target robot'). Adds value beyond schema titles but not deeply descriptive.
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?
Description clearly states 'Gets the result of a specific robot command,' identifying the action (get), resource (result), and specificity. Differentiates from siblings like list_robot_commands and create_robot_command.
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?
No explicit guidance on when to use this tool vs alternatives. Implicitly after creating a command, but no direct when-to-use or when-not-to-use statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
智能获取机器人状态。
自动根据机器人系列选择V1 (M-line) 或V2 (S-line) API。
Args:
serial_number: 机器人序列号
Returns:
机器人状态信息字典
| Name | Required | Description | Default |
|---|---|---|---|
| serial_number | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral transparency. It discloses the key behavior of automatic version selection based on robot series and mentions the return type ('机器人状态信息字典'). However, it lacks details on error handling, authentication, idempotency, or other important behavioral traits, leaving gaps.
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?
The description is very concise: a title line, a behavior line, and structured Args/Returns sections. Every sentence serves a purpose, and the most important information (automatic version selection) is front-loaded. No unnecessary words or clutter.
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?
Given the tool has 21 siblings and no output schema, the description is somewhat incomplete. It explains the auto-versioning feature but does not elaborate on how to interpret the return value ('状态信息字典'), error conditions, or how this tool relates to siblings like 'batch_get_robot_statuses_smart'. More context would help an agent select and use it correctly.
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?
The schema has 0% description coverage for the single parameter 'serial_number'. The description's Args section adds the meaning '机器人序列号' (robot serial number), which is the missing description. While it does not specify format or constraints, it significantly adds value beyond the bare schema, compensating for the lack of schema description.
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 description clearly states the tool's purpose: '智能获取机器人状态' (smartly get robot status) and explains it automatically selects the appropriate API version (V1 or V2) based on the robot series. This distinguishes it from sibling tools that may require explicit version specification, making the purpose specific and differentiating.
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?
The description implies usage when automatic version selection is desired, but it does not explicitly state when not to use it or compare it to siblings like 'batch_get_robot_statuses_smart'. There is no guidance on alternatives or exclusions, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets site information for a specific robot.
Based on: https://developer.gs-robot.com/zh_CN/Robot%20Task%20Service/Get%20Site%20Info
Args:
robot_id: The ID of the target robot.
Returns:
A dictionary containing site information including buildings, floors, and maps.
| Name | Required | Description | Default |
|---|---|---|---|
| robot_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds value by explaining the return structure. However, it does not explicitly state that the operation is read-only or mention any prerequisites (e.g., robot existence), auth needs, or rate limits. The behavioral context is adequate but not comprehensive.
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?
The description is concise and structured with separate sections for purpose, args, and returns. The inclusion of an external URL is not strictly necessary but does not harm conciseness.
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?
For a simple tool with one parameter and no output schema, the description covers the core semantics: what it does, what it takes, and what it returns. It lacks mention of error conditions or permissions, but is largely complete for its complexity.
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 the description provides the meaning of robot_id ('The ID of the target robot'), which adds value beyond the schema's empty description. While minimal, it is sufficient for a simple string parameter.
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 description states the verb 'Gets' and resource 'site information for a specific robot', and elaborates on the return content (buildings, floors, maps). This clearly distinguishes it from siblings like list_robot_maps or get_robot_status_smart.
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?
The description implies usage when needing site info for a specific robot, but does not provide explicit when-to-use or when-not-to-use guidance relative to siblings. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
智能获取任务报告。
自动根据机器人系列选择M-line或S-line任务报告API。
Args:
serial_number: 机器人序列号
page: 页码
page_size: 每页大小
start_time_utc_floor: 开始时间过滤
start_time_utc_upper: 结束时间过滤
Returns:
任务报告数据字典
| Name | Required | Description | Default |
|---|---|---|---|
| serial_number | Yes | ||
| page | No | ||
| page_size | No | ||
| start_time_utc_floor | No | ||
| start_time_utc_upper | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully explain behavior. It mentions automatic API selection but does not detail error handling, pagination, output format beyond 'data dictionary', or any side effects. Significant gaps remain.
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?
The description is short but mixes English and Chinese in a somewhat confusing way. The Args/Returns list is present but not well-formatted. It could be more concise and structured for 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?
Given the lack of output schema and annotations, the description is severely incomplete. It does not explain the output structure, error scenarios, or how the serial number determines the robot series. Essential usage details are missing.
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?
Input schema has 0% description coverage. The description lists parameters in Chinese with no additional details on format, constraints, or allowed values. For example, date parameters lack format specification, and serial_number lacks pattern info.
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 description clearly states the tool retrieves task reports and automatically selects the appropriate API based on robot series. This distinguishes it from sibling tools like generate_task_report_png and execute workflow tools, though it could be more explicit about the type of reports.
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?
No explicit guidance on when to use this tool versus alternatives like generate_task_report_png or the execution tools. The automatic selection based on robot series is implied but not elaborated, and no when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks the status of a V1 map upload.
Args:
record_id: The upload record ID.
Returns:
A dictionary containing the upload status information.
| Name | Required | Description | Default |
|---|---|---|---|
| record_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'checks the status' but does not disclose behavior for invalid record IDs, side effects, or response structure beyond a vague 'dictionary.' Read-only nature is implied but not confirmed.
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?
Description is very short (three lines) and follows a standard docstring format. It is concise but sacrifices completeness for brevity, which is borderline acceptable for a simple tool.
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?
No output schema exists, yet the description only says 'A dictionary containing the upload status information' without specifying keys or possible values. Missing details on error handling and edge cases make it incomplete for reliable agent use.
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?
Only parameter record_id is described as 'The upload record ID' in the Args section, adding basic meaning beyond the schema's empty string type. However, with 0% schema coverage, more detail (e.g., format, origin) would be helpful.
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?
Description states 'Checks the status of a V1 map upload,' which clearly identifies the action and resource. It distinguishes from siblings like upload_robot_map_v1, but could be more specific about what 'status' entails.
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?
No guidance on when to use this tool versus alternatives (e.g., upload_robot_map_v1). The context of sibling tools suggests it is used after an upload, but this is not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists historical commands sent to a robot.
Args:
serial_number: The serial number of the target robot.
page: Page number (default: 1).
page_size: Number of items per page (default: 10).
Returns:
A dictionary containing the historical commands list.
| Name | Required | Description | Default |
|---|---|---|---|
| serial_number | Yes | ||
| page | No | ||
| page_size | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'historical commands' implying a read operation, but omits details like pagination behavior, sorting, effect on system, or any prerequisites. Minimal information is given.
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?
The description is brief, using a clear 'Args/Returns' structure. Every sentence is necessary, no redundancy. Perfectly concise for a simple listing tool.
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?
The description covers the basic purpose and parameters, but lacks detail on return format (vague 'dictionary containing list'), no mention of error handling, or relationship to other tools. Given the low complexity and no output schema, it is minimally adequate.
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%, so the description must add meaning. It does: defines 'serial_number' as 'the serial number of the target robot,' and clarifies 'page' and 'page_size' as pagination controls with defaults. This adds value beyond the schema's minimal titles.
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 description clearly states it 'Lists historical commands sent to a robot,' providing a specific verb and resource. It differentiates from sibling 'get_robot_command' (single command) and 'create_robot_command' (creation). However, it does not explicitly contrast with other listing tools.
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?
The description provides no guidance on when to use this tool versus alternatives. No when-not-to-use or context dependencies are mentioned, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches the list of maps associated with a specific robot.
Based on: https://developer.gs-robot.com/zh_CN/Robot%20Map%20Service/V1%20List%20Robot%20Map
Note: This API uses POST method with robotSn in the JSON body.
Args:
robot_sn: The serial number of the target robot (e.g., 'GS008-0180-C7P-0000').
Returns:
A list of dictionaries, each containing 'mapId' and 'mapName'.
| Name | Required | Description | Default |
|---|---|---|---|
| robot_sn | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description tells it's a read-side operation (fetch) and describes return format. But it lacks details on permissions, rate limits, or side effects, which are expected for a complete behavioral disclosure.
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?
The description is reasonably concise with front-loaded purpose and structured args/returns. The URL reference adds some extra length but provides useful context.
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?
For a simple tool with one parameter and no output schema, the description sufficiently covers the return format and usage context. It does not compare to siblings but is adequate for the task.
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?
The description adds meaning beyond the input schema by specifying the parameter's role and providing an example value ('GS008-0180-C7P-0000'), which compensates for the 0% schema coverage.
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 description clearly states 'Fetches the list of maps associated with a specific robot,' using a specific verb and resource. It distinguishes from sibling tools like download_robot_map_v1 by focusing on listing.
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?
The description notes the HTTP method (POST) and explains the parameter format, providing clear context. However, it does not explicitly state when to use this tool versus alternatives like upload or download.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches the list of robots from the Gausium OpenAPI.
Based on: https://developer.gs-robot.com/zh_CN/Robot%20Information%20Service/List%20Robots
Args:
page: The page number to retrieve (must be > 0).
page_size: The number of items per page.
relation: Optional relation type (e.g., 'contract').
Returns:
A dictionary containing the robot list data from the API.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| page_size | No | ||
| relation | No |
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 mentions 'fetches' but does not disclose behavioral traits like pagination limits, rate limits, auth requirements, or error handling. The return type is vaguely described as 'a dictionary containing the robot list data'.
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?
The description is brief and front-loaded with the main action. The Args/Returns structure is clear. However, the embedded URL may be extraneous for an AI agent; it could be more concise.
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?
For a simple listing tool with 0 required parameters, the description covers the basics. However, it lacks detail on the structure of the returned robot data, which would help the agent process results. Given the output schema absence, more completeness would be beneficial.
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?
The description adds meaning beyond the input schema by explaining each parameter: page must be >0, page_size is items per page, relation is optional with example 'contract'. Schema coverage is 0%, so this is valuable context.
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 description clearly states 'Fetches the list of robots from the Gausium OpenAPI', using a specific verb and resource. It distinguishes this tool from sibling tools like get_robot_status_smart or list_robot_maps by focusing on the robot list.
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?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for fetching a paginated robot list but lacks exclusions or comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submits a temporary task without site information for S-line robots.
Args:
task_data: Task data including map and area information.
Returns:
A dictionary containing the task submission result.
| Name | Required | Description | Default |
|---|---|---|---|
| task_data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent. Description only says 'submits' without disclosing mutability, destructive potential, authentication requirements, or side effects. Barely provides any behavioral context beyond a generic submission action.
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?
Description is brief with two sentences plus Args/Returns sections. No wasted words, but the Args section merely paraphrases the parameter name. The Returns section is generic.
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?
No output schema or annotations. For a task submission tool, critical context about return values, error handling, and preconditions is missing. The loose input schema is not compensated by the description.
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 coverage is 0%, but the description adds that task_data should include 'map and area information', which provides some guidance beyond the loose schema. However, it lacks detail on expected structure or constraints.
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?
Clearly states it submits a temporary task without site information for S-line robots. The verb 'submits' and resource 'temporary task without site information' are specific, and the name contrasts with sibling 'submit_temp_site_task'.
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?
Implies usage when site information is absent, but does not explicitly state when to use this tool versus alternatives like 'submit_temp_site_task'. No when-not-to-use guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submits a temporary task with site information for S-line robots.
Args:
task_data: Task data including site, map, and area information.
Returns:
A dictionary containing the task submission result.
| Name | Required | Description | Default |
|---|---|---|---|
| task_data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden but only states basic function. No disclosure of side effects, blocking behavior, permissions, or other behavioral traits. Minimal information for an agent to understand implications.
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?
Description is very short with no wasted words. However, it could be better structured with separate sections for purpose, parameters, and returns. Effective use of docstring format.
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?
Given zero annotations, one parameter with no schema description, and no output schema, the description is incomplete. It lacks details on task_data format, error cases, and integration context with sibling tools.
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 has 0% description coverage for the single parameter 'task_data'. Description adds 'including site, map, and area information', which provides some context but is vague and insufficient to convey structure or constraints.
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?
Description clearly states verb 'submits', resource 'temporary task', and context 'S-line robots with site information'. Slightly distinguishes from sibling 'submit_temp_no_site_task' by mentioning site info, but could be more specific about the task's nature.
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?
No guidance on when to use this tool versus siblings like 'execute_s_line_site_task_workflow' or 'submit_temp_no_site_task'. Missing prerequisites or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Uploads a robot map using V1 API.
Args:
map_data: Map data to upload.
Returns:
A dictionary containing the upload result with record_id.
| Name | Required | Description | Default |
|---|---|---|---|
| map_data | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only states 'uploads', but does not disclose side effects (e.g., overwriting), idempotency, error conditions, or required permissions.
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?
The description is short and includes the args/returns section, but the structure is minimal and lacks detail. It is concise but under-specified.
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?
Given the tool's mutation nature and lack of output schema, the description is incomplete. It omits error handling, return value details beyond 'record_id', and any context about map data requirements.
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?
The description adds minimal value over the schema: 'Map data to upload' does not clarify format, structure, or constraints. The schema has 0% description coverage, and the description fails to compensate.
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 description clearly states the tool uploads a robot map via V1 API, which distinguishes it from sibling tools like download_robot_map_v1 or list_robot_maps. However, it does not elaborate on the V1 API specifics.
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?
The description provides no guidance on when to use this tool, prerequisites, or alternatives. It only defines the action without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Most tools have distinct purposes targeting specific robot operations like status queries, command management, map handling, and task workflows. However, there is some overlap between download_robot_map_v1 and download_robot_map_v2, which serve similar functions but differ only by API version, potentially causing confusion. Similarly, execute_s_line_no_site_task_workflow and execute_s_line_site_task_workflow are closely related but distinguished by site information presence.
The naming follows a consistent snake_case pattern with clear verb_noun structures (e.g., get_robot_status_smart, create_robot_command). Minor deviations exist, such as using robot_sn in some tools versus serial_number in others, and mixed language in descriptions (English and Chinese), but overall the naming is predictable and readable.
With 21 tools, the count is on the higher side but reasonable for a comprehensive robot management server covering status, commands, maps, tasks, and workflows. It borders on feeling heavy, as some tools like the separate V1 and V2 map downloads could be consolidated, but it aligns well with the domain's complexity.
The tool set provides complete coverage for robot operations, including CRUD-like actions for status (get, batch get), commands (create, get, list), maps (upload, download, list, get subareas), and tasks (execute workflows, submit, get reports). It supports both M-line and S-line robots with smart selection tools, ensuring no obvious gaps for core workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Control your Tesla from your AI assistant - climate, charging, access, and security.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
Control your Tesla - wake it, warm it up, unlock and more. Get your developer token at https://Infoseek.ai/mcp. Also requires your own Tesla developer token which is tied to your car/fleet.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/cfrs2005/mcp-gs-robot'
If you have feedback or need assistance with the MCP directory API, please join our Discord server