calendar_addCreate or update a calendar event with date, name, rating, sector, domains, targets, category, and sentiment. Maintain your monthly calendar by adding new entries or modifying existing ones.
新增或更新一条日历事件。每月日历维护入口。
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| name | No | ||
| rating | No | ||
| sector | No | ||
| domains | No | ||
| targets | No | ||
| category | No | ||
| sentiment | No | 中性 |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the tool can add or update, but does not explain how the upsert decision is made, whether an existing event is overwritten, what happens when fields are omitted, or whether the operation has side effects. This is a significant transparency gap for a mutation tool.
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 compact and front-loaded: the first sentence states the core operation, and the second gives usage context. It avoids redundancy and fluff, though the brevity sacrifices detail that other dimensions require.
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 write/upsert tool with 8 undocumented optional parameters, no output schema, and no annotations, this description is far too thin. It fails to specify the update identity key, required fields, date format, or value conventions, so an agent cannot reliably invoke 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?
Schema description coverage is 0% and the description adds no parameter-level meaning. The eight property names give hints, but the description says nothing about date format, which fields identify an existing event, the meaning of rating/sentiment, or allowed values. Since coverage is low, the description was expected to compensate and does not.
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 a clear verb-resource pair: '新增或更新一条日历事件' (add or update a calendar event), and '每月日历维护入口' identifies it as the maintenance/write entry point. This distinguishes it from the many calendar read/query siblings like calendar_range, calendar_month, and calendar_event_detail.
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?
'每月日历维护入口' gives explicit context that this tool is the intended entry for calendar maintenance tasks, implying it should be used when adding or updating events. It does not explicitly name read-only alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.