daily_operation_briefGenerate daily operation briefs from imported reports for orders, inventory, ads, and customer service. Missing data types return null to keep the brief accurate.
读取项目各类最新导入报表，生成订单、库存、广告和客服简报；缺失数据类型返回 null。
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal read-only, idempotent, and non-destructive behavior. The description adds meaningful behavior beyond that: it reads the latest imported reports and, importantly, returns null for missing data types, which is an edge case an agent needs to know. It does not contradict the annotations.
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?
One compact sentence with a clear front-loaded action, a list of generated report categories, and an edge-case behavior at the end. Every phrase carries information and there is no filler.
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 one-parameter, read-only, annotated tool, the description covers what it reads, what it generates, and its null behavior. With no output schema, an agent still lacks a precise sketch of the returned brief structure, but the tool's name and category list make the expected result reasonably predictable.
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 documents only a required project_id string with length bounds and has no per-parameter descriptions. The description mentions '项目' as the target of the operation, adding slight context, but it does not explain the project identifier's meaning, format, or source; with one self-explanatory parameter this is acceptable but not rich.
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 opens with a clear action (读取...报表) and states what it produces (订单、库存、广告和客服简报), so an agent can recognize it as a cross-domain daily briefing tool. However, it never names or contrasts sibling tools like order_summary_get or customer_service_issue_summary, so differentiation rests on inferring aggregation from the four categories.
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 wording implies this is the tool to request when a multi-area daily brief over order, inventory, advertising, and customer service data is needed. It does not explicitly say when to prefer a sibling tool, nor give exclusion criteria, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.